In my opinion, the pthread support itself works well now. But the biggest problem of the implementation is that SharedArrayBuffer, the pthread support calls for, is implemented only in Firefox currently.
One of the purpose to use emscripten is made an application cross-platform web application. You can get a "non-webbish" code runs only in Firefox with pthread-supported emscripten as of now.
I'm looking forward to other browsers with SharedArrayBuffer support, especially Mobile Safari.
I'm pretty sure it's also behind a flag and will remain so until the spec is stable enough that it won't change when it becomes standard (likely EcmaScript 2017).
I don't think reinventing is quite right, reimplementing more like it.
Remember the thing that Microsoft was afraid of for the Web? A middle layer that makes your OS mostly irrelevant.
It took a roundabout way but we're getting there. Extremely high performance virtual machines that are all fairly compatible, are deployed across a vast range of operating systems and devices today.
Together with an UI toolkit that renders fairly similarly across all these devices.
Technically this maybe can't do things that a single computer couldn't do ages ago, but now every computer can run that code. And via LLVM you can compile almost anything to js.
And with a much better security model than "download random exe and run" as well.
The sneering merely shows that you haven't really thought about what is going on here.
The VMs aren't even close to "high performance" (although they are very wonderfully compatible), and the UI toolkit is not one (it's a document markup toolkit with buttons and such glued on, it's pretty awful compared to Mac OS's Interface Builder).
And any computer can run just about any kind of code now. Ask someone to download Python or LuaJIT and they can run your code.
Security models? In Lua, you can empty the environment and start fresh. You have a perfect sandbox with the flip of a switch.
I don't think the grandparent comment is sneering. I think he has an opinion that disagrees with yours.
It's not reinventing computing it's expanding its platform -- a popular, vendor neutral, abstraction over all kinds of hardware and operating systems that allows secure emphereal usage of software applications -- to allow complex and performant applications without compromising on it's core design principles.
I'm a guy who thinks we should have pushed forward with Assembly, C, and Lisp as the stack for everything. You always have a good tool for the abstraction level you need.
>Compatibility and wide distribution is as much a technological problem as threading
No it isn't because their solution isn't actually compatible with any other implementation than FF and will only eventually get in to next versions of browsers.
The whole problem is much more political (who invents it amd trough what process depends very much on what will be adopted as clearly shown in the past) than technical so I can understand OPs dislike of bad technical solutions for political reasons.
>It's wrong to belittle browsers for reinventing the easy parts of the problem when they are the best solution we've ever had to the hard part.
Arguable, with Windows 10 store and apps integration improvement (no need for full screen apps) I can see "desktop" moving to the similar sandbox model as phones, as far as I'm aware OSX also has app sand-boxing model.
I could see a .NET or JVM based cross platform solution that would require minimal changes for UI across platforms - Xamarin style but more polished/OSS. Creating cross platform wrappers for common functionality (eg. OpenGL, File System, etc.) is trivial and already done - no need to wait for standardization body and vendors to implement it by 2020.
> I could see a .NET or JVM based cross platform solution that would require minimal changes for UI across platforms - Xamarin style but more polished/OSS.
That sounds like a good idea. Unfortunately, it's been tried multiple times by the biggest companies on the planet and has always failed.
What company had the incentive to do it right from the start ?
Microsoft did try Silverlight but I feel like because it was a wrong approach (trying to integrate in to browsers instead of making it a cross platform app sandbox) that came from the wrong company at the time (no interest in actually providing a cross platform toolkit) it failed.
As someone who worked with Silverlight - I could see a Silverlight-like framework to work on WP/iOS/Android/Win10/OSX/Linux to deliver truly cross-platform application platform - it wasn't actually bad technically - and with the recent Microsoft CoreCLR open movement the entire stack would be OSS and even better than JVM based solutions (value types for eg. are pretty big for this kind of thing as you probably know as the entire thing is full of small point/vector/etc. data structures).
Again I feel like no company is in a position to make something truly cross platform except maybe new Microsoft with focus on cloud and enterprise IT.
Google wants you to stay in the browser, Apple wants to lock you to iDevices and OSX, Adobe needs to sell you stuff to make money. Mozilla needs it to be about Internet (that's both where their finances come from and what their org is about).
I don't think this is a fair comparison - 90s and even early 2000s were extremely different from modern devices - JVM was far worse performance wise which mattered even more because hardware was significantly slower with much less RAM, internet was slow and not ubiquitous.
New JavaFX looked promising but it has it's own technical problems + it's developed by Oracle - I don't think I need to say more.
Right now I think most platforms support some form of sandboxed app model - all we need is a portable framework that can target all of them exposing a shared API but still allowing native access where needed with decent performance.
.NET/CoreCLR could be one such platform, JVM another.
C++/Qt tries to be this but honestly it's C++ - it's one of the few technologies where I'd say I'm more productive with HTML5 stack.
Rust/Servo could also deliver something similar down the road - maybe you could cut out a "fast" subset of CSS layout and DOM from servo (I'm guessing there are edge cases that make the rendering/layout hard/impossible to optimize) and have something that looks like web stack (could even be a strict subset) but is capable of doing 60 FPS GUI and at the same time can talk to the native code which can then use app/sandbox APIs.