WebAssembly and the Future of JavaScript 175
Nerval's Lobster writes: WebAssembly is the next stage in the evolution of client-side scripting. In theory, it will improve on JavaScript's speed. That's not to say that JavaScript is a slowpoke: Incremental speed improvements have included the rollout of asm.js (an optimized subset) in 2013. But WebAssembly—while not a replacement for JavaScript—is intended as a "cure" for a variety of issues where JavaScript isn't always a perfect fit, including video editing, encryption, peer-to-peer, and more. (Here's a full list of the Web applications that WebAssembly could maybe improve.) If WebAssembly is not there to replace JavaScript but to complement it, the key to the integration rests with the DOM and Garbage Collected Objects such as JavaScript strings, functions (as callable closures), Typed Arrays and Typed objects. The bigger question is, will WebAssembly actually become something big, or is it ultimately doomed to suffer the fate of other hyped JavaScript-related platforms such as Dart (a Google-only venture), which attracted buzz ahead of a Minimum Viable Product release, only to quickly fade away afterward?
WebAssembly (Score:2, Insightful)
Never heard of it. Probably a passing fade. I predict decades more of Javascript and (alas) Flash.
Re: (Score:3)
Decades more of Flash, eh? Is that the same Flash that I haven't used in over three years now?
Re:WebAssembly (Score:5, Insightful)
Here's something you might not know: Your personal use case is not representative of the world at large.
Flash is still quite popular, and isn't likely to vanish any time soon. Millions upon millions of users engage with flash content on the web daily. It's going to take a very long time for alternatives to catch-up in terms of authoring tools and, most importantly, content. It'll take even longer for that old content to fade into obscurity -- just like Java applets before it.
I know it's cool to play the ideologue, but it's foolish to deny the obvious reality. Flash is going to be with us for many years.
Re: (Score:1)
Re: (Score:2, Informative)
iOS actually sees relatively little use. Yes, selling a comparatively small number of rather expensive phones and tablets does give Apple some impressive revenue numbers, but the proportion of iOS users is very small. There are many more users using cheaper Android devices from a wide variety of manufacturers.
Look at these recent browser usage stats [caniuse.com], for example. iOS Safari is only about 7%. The old Android browser is still at over 5%, plus there's Chrome for Android at over 13%, and UC Browser for Android
Re:WebAssembly (Score:4, Informative)
Flash doesn't run on iOS, so it's already on the way out.
So said everyone ... 7 years ago. At this point, it's just pure delusion. iOS just isn't relevant.
The "major decline" you and everyone else has been on about nearly a decade just hasn't happened. Flash has declined, sure, but not significantly. Google and Mozilla recognize this, and have taken steps to ensure flash content will work in their browsers for the foreseeable future. After all, if their browser can't render the content people want, they'll look elsewhere.
I suspect we'll have this exact same discussion 5 years from now. There's just too much content and the alternatives just aren't mature enough to see any significant change over the next few years.
This is simply reality.
Re: (Score:2)
The "major decline" you and everyone else has been on about nearly a decade just hasn't happened. Flash has declined, sure, but not significantly. Google and Mozilla recognize this, and have taken steps to ensure flash content will work in their browsers for the foreseeable future. After all, if their browser can't render the content people want, they'll look elsewhere.
One would think that they could just eventually turn it into an HTML5 library...
Re: (Score:2)
indeed. All that's really happened is that Apple fans have missed out on Flash's 'killer app': http://www.misternicehands.com... [misternicehands.com]
Re: (Score:2)
Mobile browser statistics [netmarketshare.com] suggest otherwise, but OK let's join you in fantasy land where "iOS just isn't relevant" to the web.
How about Adobe? Is Adobe relevant to Flash? Because it was Adobe who pulled the plug on Flash mobile in 2011 [mashable.com]. Flash on mobile is a bloated battery-draining joke. Apple merely recognized that fact first.
And if you're suggesting that mobile web is less relevant than desktop web, you've gone full retard [smartinsights.com].
The decline HAS happened, and is still happening [w3techs.com] (are you saying a decline from
Re: (Score:2)
[...]Flash is going to be with us for many years.
Like herpes. Except that HTML5 can, and does cure it.
Re:WebAssembly (Score:4, Informative)
Re: (Score:2)
Re: (Score:2)
There were a few mentions of (P)NaCl in this interview: https://medium.com/javascript-... [medium.com]
tl;dr Brendan Eich suggests (P)NaCl becomes irrelevant over time (or it has already) and WebAssembly is the future.
Re: (Score:2)
Re: (Score:3)
You know, you're ignorant. You have no will to be informed. I think that makes it so you should be dead.
Webassembly means... (Score:5, Funny)
Re: (Score:1)
Real programmers use WebMachineCode.
Re: (Score:1)
Re: (Score:1)
Those look like WebButterflies to me.
Re:Webassembly means... (Score:4, Interesting)
You can write asm.js by hand, no so sure about WebAssembly, although there could be rare corner cases where this is warranted.
But in almost all cases this is not the expected deployment scenario. Rather, you'll write your web app in one of many different high-level languages, and it will get compiled to WebAssembly. Interestingly enough, one of these languages is C++, which has a vastly different thread and memory model compared to JavaScript. This has always been a big stumbling block as there is existing C++ code that people would like to run in browsers, but up to now there was no good solution that works across browsers.
The roadmap suggests that JavaScript will retain its robust memory and thread model, but gain enough features to support the less robust but higher-performant model used by C++. We truly live in interesting times.
This will also address the problem that JavaScript could never effectively take advantage of multiple cores, but CPUs tend to add more performance by adding cores rather than by improving single-thread throughput.
Re:Webassembly means... (Score:4, Insightful)
Re: (Score:2)
Re: (Score:2)
It has robust performance for a scripting language, running circles around Python, R (not including NumPy / BLAS / ATLAS), Ruby etc. dynamic languages; faster than most JVM based (non-Java) language implementations, and - for example, from my profiling on number crunching tasks - around as fast as Java.
Also, there are not a lot of recent reports that start with: 'Due to a vulnerability found in JavaScript, millions of credit card details were exposed'
Re: (Score:2)
Re: (Score:2)
You can write WebAssembly by hand, in the same way you can write Java bytecode by hand. You probably wouldn't want to though.
Although C++ is supported, not all of it is. The environment is heavily sandboxed too. Porting existing C++ will need some work, it's not just a recompile, although I think you realize that.
Re: (Score:2)
You can write WebAssembly by hand, in the same way you can write Java bytecode by hand.
Not exactly. WebAssembly uses an Abstract Syntax Tree, which, while available in text and binary format, is quite a bit different than just listing out a sequential series of bytecode instructions.
https://github.com/WebAssembly/design/blob/master/AstSemantics.md [github.com]
Re:Webassembly means... (Score:5, Funny)
Re: (Score:2)
6502 assembly language rocked.
Accumulator
X register
Y register
Program Counter
6 status flags packed in 1 byte
Yielding 5 registers you had to track plus the Stack Pointer. With a total of 56 mnemonics/operands. It was a joy to program since you could remember what all the registers were doing in your head. On the other hand, with only one accumulator /general purpose register available, you did a LOT of gymnastics to get things done.
Example adding $18 to a number at memory location $1020
CLC clear the
Re: (Score:3)
6502 is a very restrictive architecture. This wasn't too bad, when problems were usually trivial enough that 8 bit operations or at best 16 bit operations were needed the bulk of the time. But for any non-trivial problem these days, that's just not the case. And the limitation of a single general purpose register, a 256 byte zero page, a 256 byte stack and almost no addressing modes is just way too restrictive, if you want to start writing your programs in a high-level language; if you write tiny trivial ha
Re: (Score:2)
x86 is actually not horribly bad by modern standards. It is almost the most compact encoding that anybody has managed to come up with, and that's a good thing.
I had a crazy thought the other day that given a rich-enough set of benchmark program inputs and a modified compiler, perhaps an improved instruction encoding could be generated automatically, hand-in-hand with a compact (power-efficient) instruction decoder. On one hand, it seems like a really massive undertaking. On the other hand, shaving off bits of power consumption from future billions of devices all over the world over years of their operation could perhaps be worth it.
Re: (Score:2)
My first forays into machine code (manually constructed with a book and poked) was on a Z80... And it really was an amazingly fun experience.
These days, dealing with assembly in modern ARM and MIPS processors, while so much more capable, and having features that make writing assembly ridiculously powerful, I do miss the utter simplicity of that Z80- so simple a kid was able to pick it up.
It really was great fun.
I don't think it will gain much traction (Score:5, Insightful)
One of the big "security benefits" I've heard claimed is that WebAssembly will only be able to invoke the same functions/methods as JavaScript itself. So that implies that WebAssembly is nothing more than pre-compiled JavaScript.
As the compile phase of JavaScript pales in comparison to the execution phase, the only people I can see pushing for this are those who want DRM-style protection of their JavaScript so no one else can read it.
Re:I don't think it will gain much traction (Score:4, Informative)
An awful lot of work has gone into making JavaScript virtual machines both high-performance and super secure. This is a difficult thing to get right. It is good to see that this work can now be leveraged for other languages, rather than forcing browser manufacturers to redo the work for each and every language. In the process they'd inevitably get something wrong, and that's quite dangerous; insecure browsers mean compromised computers.
Re: (Score:3)
WebAssembly is a reduced-functionality version of Javascript that allows better optimization. That is the purpose.
Re: (Score:3)
V8 actually has two JIT compillation modes exactly because of things like this. One handles "easy" functions and the other handles "hard" functions (functions that contain eval or try and catch for example), the "easy" compiller has worse performance. This link explains it well:
https://github.com/petkaantono... [github.com]
Great read for people who want to optimize for V8, many of the tips should be valid for other javascript engines as well.
From the article:
Currently not optimizable (ie will use the slower compilation
Re: (Score:2)
Yes, it's interesting how often the newly introduced ES6 etc. elements are slower than what they replace, even though the ES6 version is typically saner and more conducive to optimization. For example, Maps are probably still slower than the current string based objects. But we don't have to go that far. A couple of years ago there were bug reports about the performance of typed arrays. The very point of typed arrays is that they can be made faster (and of course WebGL support through number type representa
Re: (Score:2)
Yeah it is because the optimizing compiler does not know how to optimize those things yet. But in reality having a proper examinable bytecode would be better for those times you actually need every little bit of performance. Examining the bytecode of your own code is easier than trying to understand the compiler (badly documented and forever evolving) optimizations.
Re: (Score:2)
Since it's JavaScript, you probably meant assembly?
Re: (Score:2)
WebAssembly is a bytecode, from my understanding not much different than Java.
Re: I don't think it will gain much traction (Score:1)
WebAssembly (WASM) is, at least initially, just a ASM.js with better compression (binary). You can even convert losslessly between ASM.js and WASM. And do remember that ASM.js is just a subset of JavaScript that removes slow features, so you can convert all the way back to plain JavaScript from WASM. ASM
Js proved that JavaScript subsets could be almost as fast as native, and that killed any justification for Googles Native client (Nacl/pnacl) which if popularized would have added 8mb of undefined behavior t
Re: (Score:1)
Re: (Score:2)
Re:I don't think it will gain much traction (Score:5, Informative)
That is possibly true, although details will still need to be seen. asm.js programs typically allocate a single static memory region that they than manage themselves without bothering the JavaScript VM to track memory references. In fact, a asm.js program doesn't have access to garbage collected objects. As soon as it tries to access those, it falls back to JavaScript mode (every asm.js program is by definition also a valid JavaScript program, but not necessarily vice versa).
WebAssembly programs at least originally will do the same as asm.js. It is possible that as more experienced is gained with this feature, there will be a way for WebAssembly to tap into the garbage collected pool of objects. Only time will tell.
TypeScript (Score:2)
Re: (Score:2)
LOL Angular 2.
Pre-ES6 browsers (Score:2)
But is ES6 polyfillable, or does it require serving transpiled pre-ES6 files to pre-ES6 browsers?
WebAssembly (and asm.js) solved the boot strapping (Score:5, Informative)
Previous attempts at replacing JavaScript always suffered from a boot strapping problem. While there are only a small number of major desktop browsers, overall, there are actually a lot of different minor browsers that people expect to work. And even among the desktop browsers, not everybody always runs the most recent release.
Content producers don't really like writing content that only 30% of their users can view. So, unless a new technology is rolled out to 90+% of the deployed browsers, nobody is going to write content for it. On the other hand, if nobody writes content, the rest of the browser manufacturers won't put any resources into adding support for the new technology.
Both asm.js and WebAssembly have a fallback mode that uses plain JavaScript, as available in virtually 100% of all browsers. Performance will obviously be degraded, but that's much better than making the content completely inaccessible. And users are more likely to upgrade their browsers, if they can see a low-fidelity version of the content and know by switching to a newer browser they'll get the high-fidelity version. So, unlike the previous scenario, this is actually a virtuous circle.
Exclusive native apps still exist (Score:2)
Content producers don't really like writing content that only 30% of their users can view.
Developers of exclusive apps for Mac, iOS, and video game consoles have historically not had much of a problem with limiting their market. They think they can get a better overall return on investment from targeting OS X only compared to OS X and Windows, or iOS only compared to iOS, Android, and Windows Phone, or one console compared to all consoles plus Windows PC.
Re: (Score:2)
A application that only sells in the Apple store is very different from a web site that can only be viewed with an iPhone.
Re: (Score:2)
Trying to avoid DWAD [logicallyfallacious.com]:
A application that only sells in the Apple store is very different from a web site that can only be viewed with an iPhone.
In what way, other than that one is wrapped in a UIWebView and one isn't? I'm curious as to your reasoning.
Re: (Score:2)
There's no expectation that an Apple Store app is going to work on Android, or a windows laptop, or a PS3. When I look for Android apps, I check an android app store - I know that the vast majority of what I find will work on my device.
But everyone who visits a website expects that website to render and work for them - there's no segregation between "the apple web" and "the microsoft web" when you're at your computer, it's all just one big pile of sites. Users are aware that sometimes there are browser-spec
Re: (Score:2)
Non-iphone users would try to use your website and be unable to. This will make your software look crappy, which will cause bad reviews and diminished PR. Look at games- you can develop for just PS4, and that's fine because a PC user isn't going to even try to use it. Release an unusable PC port like the latest Batman game, and you get complaints, bad reviews, and lost sales because everyone's heard how crappy the game is.
Re: (Score:2)
Non-iphone users would try to use your website and be unable to.
I already get that, with sites such as Instagram and Vine requiring download of a phone app just to set up a commenting account.
Re: (Score:2)
> Non-iphone users would try to use your website and be unable to. This will make your software look crappy.
BS. You can traverse any number of urls in your favorite browser that are not supposed to open for you, ever, because they are API endpoints, behind authentication wall, or any other reason. Nobody prevents me from deploying a customized http://thenewestiphonesonlytha... [website.com] and just plain redirecting anyone and everyone whose user agent looks even slightly off. And if you got there by changing your us
Different languages (Score:5, Insightful)
Emscripten (Score:3)
What does matter is that it may open up the development of software for execution inside a browser to a wider variety of languages
That already existed: Emscripten compiles any language with an LLVM front-end, such as Clang++, to asm.js. Apparently one of the goals of WebAssembly is to make Emscripten more practical.
Re: (Score:2)
Exactly. Think of asm.js as the proof-of-concept and WebAssembly as the production-ready solution.
asm.js was a very valuable first step to get the browser vendors on board. But WebAssembly will push much further. Most importantly, it intends to support POSIX threads for languages such as C++. That's something that asm.js never knew how to address.
Re: Emscripten (Score:2)
I proclaim Larry's Law:
Those who fail to understand Java will attempt to reinvent it. Poorly. And compile it to JavaScript.
Re: (Score:2)
Those who fail to understand Java will attempt to reinvent it. Poorly. And compile it to JavaScript.
Given the current state of Java-inside-the-web-browser, I don't see how they could do any worse than Sun/Oracle did...
Re: (Score:2)
Well you see, if you broke the rules and read the article, they're defining a new intermediate code format that's kind of like Java byte code (not really, but the intent is somewhat similar).
This "WebAssembly" is an abstraction over real hardware, that is compiled just in time so it can be executed on the native hardware or converted to JavaScript and interpreted by a VM.
Personally, I think it's cool but it's definitely reinventing a lot of concepts Java tried, succeeded at (cross platformness) and hilariou
Re: (Score:2)
They can compile C++ to javascript for fucks sake, see emscripten.
Re: (Score:2)
I have never really heard a GOOD reason for Java to be in the browser to being with. Ever... Enlighten me if you wish. I am truly curious - legitimate question.
Originally Java was intended to fill all of the custom-client-side-logic use cases that JavaScript (and to a steadily shrinking extent) Flash do now. But it didn't do a very good job of that, and instead found its calling on the server side.
Re:Different languages (Score:4, Insightful)
JavaScript isn't necessarily such a bad language; otherwise, we wouldn't see Node.js gaining so much popularity.
But you are of course right, that there isn't a one-size-fits-all language, and there are plenty of problems that can better be solved in other languages. Allowing more choice of languages for web apps is a good thing.
Also, some of the more advanced JavaScript features that are in the pipeline (or starting to be deployed) are really cumbersome to program manually. All the work that will allow implementing pthreads in JavaScript is really low-level. It'll be nice to have compilers that target these features.
Re:Different languages (Score:4, Insightful)
JavaScript isn't necessarily such a bad language; otherwise, we wouldn't see Node.js gaining so much popularity.
Bandwagon appeal. With your UID, you ought to know better. Provide a technical argument and/or step away from the keyboard until you've thought it over. Note that I'm not saying there isn't a good reason--only that your given argument is crap.
Re: (Score:2)
object notation, lambda, c syntax.
Read JavaScript: The Good Parts by Douglas Crockford.
Actually pretty impressive for javascript to become leading web scripting language.
Re: (Score:2)
I think weilawei really meant to say: "Provide a technical argument for why Node.js is gaining so much popularity." I am not sure if your post does that.
The features you listed are in pretty much every other major language. The book you referenced is a somewhat tongue-in-cheek look at how to use the good parts of a bad language. The conclusion I reach from those points is "yeah, it's bad, but see how people took the good parts and made it useful." Which doesn't really support the argument for why it is
Re: (Score:2)
> Actually pretty impressive for javascript to become leading web scripting language.
WTF? It's the only game in town. What language did you expect to become successful? Any other language requires a plug-in which makes it not universal - so therefore we all just stick with what's going to run across all the browsers - even though it's a shitty language.
People who don't want any JavaScript (Score:2)
For some reasons some people think that on the WEB there should only be that crap that javascript is.
I think some of the problem is that some codgers think the World Wide Web is the wrong place for interactivity in the first place. They want to read static documents. And if they want to interact in any way, they prefer doing so through POSTing a <form>. Finally in cases where the form paradigm is not enough, they prefer native apps such as an SMTP/IMAP, NNTP, or IRC client. They don't want any JavaScript, much as the couple in that Monty Python sketch didn't want any SPAM luncheon meat.
To those peopl
Re: (Score:2)
Yeah, but those applications that do target multiple platforms natively will offer superior experiences for users of those platforms while they all interact with one another. The last thing I want to depend on is yet another browser based turd that's here today, gone (or butchered) tomorrow.
When an installer for your OS doesn't exist (Score:2)
Until now I always assumed people would chose to run the installer designed for their operating system.
That's fine if an installer designed for your operating system exists. So let me rephrase: If someone releases a new native app for communication over the Internet, good luck installing a Windows .msi on your Mac because there's no .dmg or a Mac .dmg on your not-Mac because there's no .msi or .deb or .rpm. Or is every developer expected to provide 14 different installers for each application, one for each of 14 operating systems?
Re: (Score:2)
what you think getting the app working on all of the constantly changing set of hundreds of browsers, all with different addons, security settings, cache settings, etc. will be any easier in the long run?
Depends on how long the "long run" is. Several of the 14 platforms I have in mind have application deployment costs that far exceed the cost of a domain, hosting, and (if needing EV or if launching prior to the Let's Encrypt rollout) a TLS certificate. Many require all code to have been signed with a digital certificate from the platform's monopoly CA, which costs $100 per platform per year. Some even require each developer to be an established company, not an individual, and to undergo assessment of releva
Re: (Score:2)
I'm not so sure that JS is crap. I started learning Javascript a few months ago and I'm actually much more impressed by the language than I thought I'd be. It has a lot of functional programming features that I like, it's easy to write and quite forgiving. There are some weird things I'd rather not have seen (like variable hoisting, although I understand why it's there), but in the main I've seen worse languages.
Re: (Score:2)
JavaScript has a couple of really ugly warts (I'm surprised you mentioned variable hoisting, but left type coercion out), but fortunately with a little bit of discipline most of these issues can be avoided quite easily.
It is extremely flexible, and you can implement a large variety of programming paradigms with it. Unfortunately, it lacks some of the syntactic sugar to make this easy. So, short to medium size programs usually work great. Larger programs get cumbersome at some point.
Fortunately, there are al
A practical response: (Score:1)
We'll use it when it has 95% browser support. And no, polyfill doesn't count.
Oh look, another dice clickbait (Score:5, Informative)
Re: (Score:2)
Rant: The Web is Bleeped Up - Redo! (Score:2, Interesting)
It's time to rework the web presentation and GUI (non) standards. There are too many layers in the current stack, and it relies on fat clients where large GUI libraries and GUI-related code have to be potentially downloaded for every site. It's very poor factoring of tools, libraries, and bandwidth. The bulk of GUI libraries should be part of the browser.
I suggest we start over with 2 new standards: one for a practical work-oriented CRUD & down-to-business browser (or browser mode); and one "eye-candy"
Re: (Score:1)
That can't work for a simple reason. Half of the people working on all these standards are downright retarded, and only failure in the real world gets them to realize it. Google's and Microsoft's representatives are the worse offenders, trying to stick their obsolete development practices in the browser, and failing over and over and over. (Hell, THIS is yet another attempt by them along with Mozilla)
They'll be the first ones trying to manipulate any kind of new standard, and what you'll get will be a weird
Re: (Score:2)
* The browser provides basic building-blocks (for display, execution).
* Vendors supply programmer-friendly frameworks on top.
For example, HTML5 allows you to create custom tags, which frameworks like angular.js makes plentiful use of. In fact, some people who use Angular.js don't even know how to write plain old html/javascript. Sad but true.
If WebAssembly succeeds, it will do the same thing to javascript. JS will be gone, and you can use whatever language you w
Re: (Score:1)
Yes, but it usually becomes a revolving fan-boy circus with rapid generations and new frameworks-of-the-week. Plus, cross-browser/version compatibility is still tricky. If you have public-facing sites, you need to support old browsers.
We need the equivalent of a GUI-Oriented Netscape to come along and shake things up. Being a "product" tends to lock things down for long enough for a standard to catch on. JS/Dom Frameworks are too malleable to establish a
Re: (Score:2)
Yes, but it usually becomes a revolving fan-boy circus with rapid generations and new frameworks-of-the-week.
That's how it is now. And it will only get worse for a long time into the future.
Or better. I like having lots of frameworks, even if most of them (all of them?) are lousy.
Re: (Score:1)
But you'd need to have fairly different builds each for Apple, Linux, and Windows.
Which may be tricky for OS's that have decades of cruft for backwards compatibility or archaic conventions that are too established.
Re: (Score:2)
Hey now, don't laugh at that idea. Sites like Bloomberg could use that to interface their mainframes straight to trader's screens in a browser, and knock a fraction of a second off the update time...
"Callable closure" - closure != anonymous function (Score:2)
Minor apologies for being a bit pedantic, but just in case anyone's confused by the possible misuse of the term "closure" in the summary...
From the Wikipedia entry on closures [wikipedia.org]:
Re: (Score:2)
Why would an anonymous function need to be a function literal? What if it's the result of a compose, or some other higher level function?
Re: (Score:2)
Technically, the anonymous function is just the literal in code, and it's only "anonymous" because the programmer didn't give it a name—the compiler will sometimes assign it a generated name, but it will sometimes do something else (eg. reuse code from elsewhere in the program, roll the function into the caller, etc.). It becomes a closure when that function is combined with a scope.
So higher level function would return a closure value, which would be the function bound to the values in scope. Those a
Re: (Score:2)
Thank you for the explanation, as an FP user I didn't have an issue with the concept of anonymous function vs. closure, so let's forget about closures - e.g. assume that there is no variable capture and all functions are pure - and let's stick to the meaning of anonymous functions as defined by the cited wiki page.
If I have functions f and g, and have a higher order function C, which, for example, composes two functions, then C(f, g) is a definitely a function. Also, it is a function that has no programmer
Re: (Score:2)
You're definitely right about the Wikipedia article glossing over some of the specifics, but I'm not sure I agree that the dichotomy is false. (I'll have to dust off the cobwebs a bit—I first learned this stuff when I was studying CS at Carnegie Mellon way back in the early '90s. :)
My understanding is that one important reason to separate the literal function from the closure (function + scope) has to do with separating syntax from semantics. You the function itself just gives you the symbol manipulat
Summary of use cases (Score:1)
Why? Widgets are the one thing that Javascript does right? And I doubt you will see a difference in performance as its sync access to the framebuffer that usually slows down 2D graphics drawing on modern hardware.
> Image / video editing.
Why would I do this in a web app? And the issue with doing this in a web app has to do with taking better advantage of the UI interaction model (using tou
Obligatory link: The Birth & Death of JavaScri (Score:2)
Gary Bernhardt was ahead of the curve with his extremely amusing talk The Birth & Death of JavaScript.
https://www.destroyallsoftware... [destroyallsoftware.com]
A look back from the year 2035, he talks about the importance of having a assembly language for the web (asm.js) and tongue and cheek allowed the world to move past JavaScript where it finally becomes both a dead language and also what everything is built on.
Easy answer: (Score:3)
Find a feasible FOSS replacement for Flash that enables fast and easy cross-plattform development for performant non-trivial 'good-looking' client applications - and you have a winner. Offer some tacky half-assed JS cross-compiler nonsense, and your new tech won't get off the ground. The Web and DOM tech is a mess enough as it is, without yet another PL/runtime solution thrown into the mix.
However, I remain slightly optimistic that this may be the long awaited not-fucked-up-by-adobe FOSS Flash successor we've been waiting for. All other non-foss contenders failed throughout the last 15 years, but this might have a chance, also since there is nothing else around and the web has taken over as platform of choice due to 80ies style tech fragmentation via the mobile revolution.
Two cents from a senior webdev.
Use Cases (Score:2)
To summarize the linked page...
Intended Use Cases:
Really, the only type of programming not listed there is hard real-time. Way to narrow your focus, guys.
Web Workers (Score:3)
Hello, it's 2015, where's my MULTIFUCKINGTHREADING?
What problems have you run into with Web Workers [mozilla.org]?
Re: (Score:2)
WebWorkers allow multiple threads of execution, but they don't support a shared address space. For some applications this is acceptable. For others, not so much.
And for any application that previously existed as a C++ application using pthreads, WebWorkers just don't work at all.
WebAssembly is working on a solution to this problem. This is one of the most exciting features that WebAssembly promises.
Re: (Score:2)
I think he meant native multithreading and sorry to say, it ain't coming. JS was designed to be a single threaded, event driven language. It will never be multithreaded as it would break events and that is a problem with all event based languages/programs. You're stuck with the speed of a single core, fine for general purpose processors where you just throw more power at the problem (110W/CPU for modern systems) but really bad on low frequency/power multicore systems.
Re: (Score:2)
Isn't it true that when you need a lot of performance, in particular, on parallelizable tasks, then the workload in question is typically number crunching? If this is the case, then it is useful that web workers allow us to pass typed numeric arrays back and forth via reference. It is not a fully general solution to parallelism, but what are the use cases when it's insufficient?
Re: (Score:1)
For fuck's sake, tepples! Look at the goddamn page you just linked to! Look at the section about browser compatibility. Do you see all of those "Not supported" entries, especially for the mobile browsers? That's what's wrong with Web Workers. Just like most newer web technologies, and even some older ones, the lack of cross-browser support renders them useless!
Re: (Score:2)
Re: (Score:2)
80ies are calling. They want their GOTOs and error handling paradigms back.
Re: (Score:2)
That shouldn't be terribly difficult.