No it won't.
This is our one chance to kill javascript; if we don't do it now, it'll be entrenched forever, and best we'll ever get is 'compiles-to-js' languages like clojurescript and typescript.
Let's be realistic; who has the man power, community good will and business savvy to push an entirely new language across all platforms, mobile and desktop?
Microsoft? Come on. Apple? Google? Google tried with dart and failed.
Who else, seriously, is going to step up?
We can day dream about the magical 'no js' world, but it's never going to happen if web assembly doesn't work.
Currently we're seeing the reverse, js stretched off the browser, onto the server, into mobiles, onto iot devices.
You've got to layout some pretty damn fine arguments about why that trend is going to suddenly reverse.
Web assembly is pretty much our last best chance to flip javascript off and have something better...but it might already be too late for that to work. :/
Do people really hate JavaScript that much? I've grown fond of it in recent years, especially after ES6.
Granted, that was back in 2008 and most of my complaints have been addressed now almost a decade later (except for destructors, it still doesn't have those, but I also don't need them anymore).
These days I move between JavaScript, Python, Go, and C seamlessly and I can honestly say that I don't hate any of them as much as clients, managers, and 3rd party code.
[1] http://davywybiral.blogspot.com/2008/01/javascript-bad.html
I would never debate that. I think language choice for many people is a personal decision. There are some that I will hold my nose and use; not even complain too much. There are others that the minute there is an alternative to, I would use that instead. JS is in the latter camp for me.
If it helps, my current favorite language is Rust... they may be syntactically similar, but I just can't stand the semantics, or lack there of, of JS.
Yes. People really hate C that much. C++ brought some sanity to the language, but I continue to be firmly in the camp of continuing to hate and despise its existence.
For browser programming, or full stack in a single language, you have less choice, and none if you reject transpiling.
Anyway, the nouns are important.
It's a great container for reducing the work to deliver code across platforms.
JavaScript is a necessary evil right now; it's the least common denominator for delivery. I would probably choose typescript if I were starting a new app right now to target it, though I want to play with Rust and webassembly soon.
It's success is not bc of JavaScript; it's because it merges the cross platform Dev experience.
wouldn't you rather just run ES6 right in the browser instead of compiling it first at all?
For example, on the type of projects I work on, all tooling is certified by customers IT and anything extra requires change request, that might get approved, or not.
Too many of the silent developer masses (probably mostly back-end engineers) have and continue to feel this way about being stuck with JS. The genie's out of the bottle, it's not going back in.
I haven't used it yet, but the demo from Anders looked good. It's an attempt to fix the "loosey goosey" nature of javascript. I would be great if browsers supported it as a built in language.
https://channel9.msdn.com/posts/Anders-Hejlsberg-Introducing...
If you watch the video, you'll notice the argument notation is name: type rather than type name. I think Anders is reminiscing about his Delphi days.
ActionScript and the proposed ECMAScript 4 also use the name:type notation, so there is definitely some prior art in the web sphere
You have algebraic types (well, 99%), union types, and concise ways of expressing tree types.
I would imagine it is more pleasant than Swift or Go, though I haven't used either of those very much.
(Which isn't to say that there aren't other questions like efficiency and already-existing codebases written in other languages.)
JavaScript is freaking everywhere.
Your DMS? Chances are it understands JavaScript.
Your scanning software? Understands JavaScript.
Your security gateway? JavaScript.
You API management software? Also JavaScript.
And a ton more. JavaScript is here to stay.
It could have been JS, but it was strangled to death by Sun (on the client).
When I read this I realised that WASM might just pave the way for something more fundamental: browser runtime stdlib.
One of the big issues, even highlighted in this very thread, is that people are wary of forcing 10MB+ blob downloads on their users. What would the effect be if browser provided a proper stdlib?
Linux + BusyBox is less than 2MB (I've fitted it in floppies not too long ago) if you don't include the drivers for everything. I've created a 10MB binary set that implements an entire email server, with everything statically linked, and in Haskell (that leads to inherently big binaries).
but i wouldn't hold my breath for 1990's style java applet loading throbbers to come back into fashion. there's a reason that stuff got outcompeted by the supposedly "inferior" javascript.
what wasm competes with is flash games, insecure java applets, and npapi and nativeclient in general.
Take a look at the source for any molasses-slow news site. The only site-specific JS will be jQuery, and a few basic event handlers to do things like show and hide elements, which could have been done with CSS.
99.9% of the JS will be advertising, analytics, and tracking. People understand that these sites are tracking them, but I think most people have not idea just how much tracking is going on. Major news sites have hundreds of tracking libraries loaded per-page. That is the only reason they are slow.
I travel between countries and of course I hate staying in huge cities because they're expensive and noisy. But when you move to smaller towns, there're usually limited options for connecting to the Internet.
Last year in India I spent 2.5 hours incessantly trying to open my bank website to make an urgent payment. All these huge React/Redux bundles were loading for ages, and they aren't cached and there's no support for resuming download after it dies because of some timeout or because you were looking at the spinner for 30 minutes and decided to click reload button.
And even when these huge SPA load, they're totally broken on slow connections. People become lazy and they don't handle timeouts and responses coming in weird order because of the slow channel. Even if you manage to open SPA on slow connection, it's a pain to use, almost impossible with all these XMLHttpRequests on every click transferring megabytes of data after every click or typing any letter. :(
that's peasant level net :P. 100 or bust {literally what I have home and better at work). seriously though, indeed the web is overbloated and I don't think there is coming back
Had Apple not forbidden Flash on iOS, there would be no JavaScript superiority to talk about.
If wasm doesn't overtake JS, something else that offers native bindings to other languages will eventually. There are huge benefits to be had for teams that want to be able to code their full stack in a language that isn't JS.
We never asked for JavaScript (well the vast majority of us), but we've been stuck with it for the past two decades for all things web. Now that a doorway to replacing it with a general-purpose solution has been cracked, I expect the industry to kick it wide open as soon as possible. Not because JS is bad per se (it has certainly gotten much better), but because a lot of developers would simply prefer to use something else.