Sent: Friday, March 22, 2019 at 11:26 AM From: "Ole Ersoy" <ole.ersoy@...155...> To: inkscape-user@lists.sourceforge.net Subject: Re: [Inkscape-user] Mission
On the surface, it's a fine idea, but then you quickly run into the fact that there is only one event loop so only one function can ever be running at once,
Web workers can run background parallel computations like math done while rendering.
https://medium.com/techtrument/multithreading-javascript-46156179cf9a
no matter how many cores you have. Then you get into async hell.
ES7 will have Observables built in. Use RxJS or Promises or any other package more specific to the use case to avoid this.
If you want to port it to something, I would port it to Qt so that it "just works" across the board.
Except for in browsers which is the most leverage use case for applications that want to leverage collaboration capabilities.
Also there are efforts within the Qt project to support web assembly and all that. But ripping out GTK at this point is a daunting task, but at least you can map it mostly 1-to-1 with Qt, with Qt being a toolkit with cross-platform as its stated objective.
It's old tech and the internet is not embracing it, which means it will not benefit from all the effort going into the broader ecosystem.
You're making my point.
Yes, everything is solvable by some future version of Javascript. However Javascript is a relative disaster full of inconsistencies. Still not bad for a language that was invented in 1992 in 10 days. It's great for tinkering on webpages, but there's no large scale formal software built with it. (For a variety of reasons)
Also, I said async hell, not callback hell. The fact that some statements return a promise and others don't... well it's confusing. Where must I sprinkle these "await"s?
By all means if you want a web-enable Inkscape don't let me stop you. I was just trying to make the point that the existing code base does not resemble what a JS version would look like, at all. WebWorkers and a single event loop and async and sandboxing aren't anything the project's source code takes into account now.
Qt is pedigree tech, and it's plenty embraced. Tesla, Mercedes, etc, all use Qt. I regularly use it for embedded, desktop (mac, linux, win) and mobile (iOS/Android). Hardware accelerated, with multiple concurrency mechanisms. The problem with JavaScript is there's a new popular web framework every 6 months, so by the time you're done your Inkscape port, someone wants to do it in yet another hip new framework.
Anyway, no one is changing Inkscape from GTK, so this is all moot.