To me JavaScript is very similar to VBA. Based on its own merits it’s a pretty average language with lots of design flaws. But it has a monopoly for what it does (browser/cross platform vs ms office scripting) and most of its users never really got a chance to solve the same problems with a better language. And like VBA, it is probably the only language known to the bulk of it user base (semi-amateur web designers vs ms office business users).
I care less about the performance benefits of web assembly than the fact that it will open browser/cross platform scripting to other languages and I’d be curious to find out if we are still talking about JavaScript in 10 years.
Atwood's Law: any application that can be written in JavaScript, will eventually be written in JavaScript. (2007)
I personally find all programming languages limiting in one or another way and I use almost daily C#, Python and JS (sometimes I use other programming languages as well).
That's life, some languages are better at different things; expecting any language to be all things to all problems is what eventually leaves you feeling like it's all hopeless I expect.
bash is good, for chaining small utilities together.
python is good, for single-threaded problems which don't hurt performance
go is good, if you don't want to manage memory and need easy concurrency, strong typing/etc
rust is good if you want to prevent having a footgun and low level access.
C++ is good for giving you complete control over hardware.
R is good for data science (although is being supplanted, many say, by python).
Javascript doesn't have to be the "best" if it's not competing at all things, unfortunately, as Jobs famously said: "The future is web applications" and now javascript (which, if we remember is from a spec written by 5 guys in 2 weeks) has to fit all use-cases... it's a tall order for any language.
That’s appropriate: it is also the case that any application that can be written as an Excel spreadsheet will be (and has probably already been) written as an Excel spreadsheet.
The crucial difference with VBA is its openness and community-driven evolution. VBA is stewarded and designed almost entirely by Microsoft whereas there are many many stakeholders involved in Javascript, and it's certified by an independent body and has lots of different variants that complement each other. Also it has many "cousins" such as actionscript or swift which you can get up to speed quite quickly in once you know JS. I don't believe VBA has the same degree of transferable skills.
Exactly that. I recently started programming JS again after not using it for a while and was surprised about some of the new language features. It certainly develops in the right direction, IMO.
VBA, on the other hand, hasn't really changed at all over the past decades. It's still as annoying as it can be with no help from the IDE. That's helpful as scripts from Office XP usually run with only minor edits but it also means that flaws annoying a decade ago are now much more severe. Luckily, we'll get JS on Office, although it'll probably take another decade until a reasonable share of companies have upgraded to a version that supports it.
>Based on its own merits it’s a pretty average language with lots of design flaws.
I don't really judge a language based on the number of design flaws. That is like judging a computer based only on its specs.
>and most of its users never really got a chance to solve the same problems with a better language.
I don't really think there is such a thing as "better languages". Also your statement is probably true, and was said about php as well. It is only true though because it has the most number of people using it, so will have the highest percentage of casual programmers. As with php though, you also have very good programmers using it.
I am not really sure what the point of characterising the users is other than to subtitute for a lack of any arguments related to the language. But of course, the arguments on these topics are just a bunch of copy and paste from "list of reasons javascript sucks" articles. These just list design flaws like === and so on.
"My PC is better because it has 2GB more ram than the mac". etc....
>web assembly
Web Assembly is not supposed to remove javascript, it is supposed to be used in addition to it when you need high performance. If people try to promote it as a way to not have to use javascript, it will just result in a more fragmented client-side programming situation, where libraries are not available for particular languages, etc.
> Web Assembly is not supposed to remove javascript, it is supposed to be used in addition to it when you need high performance. If people try to promote it as a way to not have to use javascript, it will just result in a more fragmented client-side programming situation, where libraries are not available for particular languages, etc.
I guess you have been missing the news what is being done in Go, Java, .NET, Rust, Unity and everyone else regarding WebAssembly.
We will have the revenge of plugins, like it or not.
The only way out is if the browser vendors backtrack and remove WebAssembly support.
There are lots of developers that stayed as backend engineers as they couldnt stand javascript (as a language and its integration with DOM), they stepped over the beginner phase with their development skills while javascript forced them to write BASIC (LOGO) level code. On the top of it, there were always some junior engineers that barely started to develop and were playing smart and bragging how cool the javascript is. There is a lot of rage stored in those circles and there are lots of excelent developers (I can tell you that 90% of top developers (not 25 years old kids, people that are able to write runtime compilers and OSes if given enought time) I know never wanted to work in javascript). Different reasons but I can tell you that most of them would say "I dont like java, but javascript is humiliating".
Now the webasm is comming, I am preparing to bet that the frameworks will start to pop out in year or something after DOM is supported and they will overrun javascript in shortest possible time, just to prove the point - it sucks big time. QT is beeing prepared, all the "real" languages are starting to prepare to support compiling into webasm... the traditionally backend languages (that... you wouldnt believe... backend engineers know very well) are now having a chance to shine in browser that was restricted for them due to javascript monopoly.
I wouldnt take the javascript future as really bright, in best case it will be used in same way as today shell scripts are (this is what they meant that webassembly is not replacement for javascript). To glue some parts of "system" (read as: browser) together.
And quite frankly, this is step that should be done 10 years back. It would save world a lot of trouble.
Consider python. With all the built-in libraries, it's many MB of code. If my app is 1-2mb, I'll be pushing the limits (I'll definitely be looking at multiple bundles to reduce and spread out the load parse time).
If that goes up to 10-15mb (which can't be split), you're now going to have major usability issues. That's before all that analytic stuff that isn't going away. People do notice the difference and will just leave.
Unity complex with basically zero runtime and uses webgl so it doesn't need to include that either (just the actual game itself).
People use the Dom because it's standard, doesn't have to be downloaded every time, and offers tons of features.
Nobody is going to write directly to webgl for a standard website (That's easily 9,999 out of 10,000 sites). That means you have to do something like drag Qt or GTK everywhere which takes even more time to download and parse.
Your idea seems to be: download and parse a bloated runtime, download and parse a huge display library set, download and parse the misc shim pieces, and then download and parse your app. This is all done with the hope that your crud app that spends most of it's time doing nothing will be a fraction faster and you can write it in something that isn't JS.
I love the idea of wasm allowing other languages, but it's going to take at least a decade to be usable for anything aside from heavy number crunching with C++. For a webpage, replacing the DOM with UI toolkit X is a pipe dream with problems ranging from aria/accessibility to web crawling and indexing issues.
Adobe won't be bringing flash back. It was basically just ES4. ESnext and HTML5 have almost all the good stuff plus quite a bit more while having far better performance than flash could achieve.
Sorry but I believe you are wrong in basic presumptions. If they will do it properly, in c++ compiled to webassembly scenario, there will be no need for parsing (except some headers). Browser code (V8 in chrome?) will just take the opcodes and execute them, similar as CPU execute machine code in native applications. But normally, if this is a scripting language like, lets say python, that webassembly compiled python "runtime" will need to parse python source code (or not, there are pycs if I remember correctly) and there will be parsing overhead. But for compiled languages there will be "no" overhead (browser on its own is overhead) and in any case far less than for javascript (that really needs to be parsed).
Anyway, if you remeber flash, there was one runtime for all flash apps and once you had it, this was it (until next security update :D), and with todays CDNs, it will be no different than, for example, angular. Downloaded once, cached forever.
First, I suppose I'm obligated to say that I'm a huge fan of Wasm (and was a huge fan of pnacl for years before that).
Wasm (like asm.js before it) is target at unmanaged languages. A C++ codebase likely does very well with good performance. That was not what I was talking about. Convincing a game company to write their games in C++ is trivial. Convincing that same game company to write their normal CRUD website in C++ would be incredibly difficult.
Looking at apps, there's still issues. Consider Qt. While it's very possible to write everything in C++, loads of companies jumped straight onto the QML/JS bandwagon because its (generally speaking) much faster to write safe code in JS (also, running the v8 version that Qt requires would be terribly slow compared to the native engine). UI development is hard no matter what and C++ doesn't do it any favors. JS features like closures and dynamic objects make many things easier than static classes functions.
This means we need to look away from C++ to something that is managed and has faster code turnaround times. The best possible languages for this are (IMO) Scheme (or maybe Common Lisp) and SML (or maybe Ocaml or F#). You could also make arguments for something in the vein of Dart or Kotlin.
How do you bring these languages to wasm? If you use a JIT, you run into a rather large payload (4-10mb of code is going to have obvious impacts). In some cases like Ocaml where a native compiler to wasm is in the works, you still have a GC issue (basically, you can make an advanced GC that is slow or a basic GC that is "fast", but with other issues).
The addition of DOM API will solve the GUI issues (and maybe they'll rework them to be more like dart's API). Adding hooks into the builtin GC would reduce payload size down to something closer to unmanaged languages. 10 years after those are added (when outdated browsers can finally be ignored), wasm will finally be ready to replace JS.
Adding those features doesn't seem to be highest priority. Unfortunately, you and I will probably be nearing retirement age before they are generally usable.
As a point of interest, JS code could be getting much smaller and much faster to parse (plus becoming a better compilation target) with the JS binary AST proposal.
I agree. DOM will come, thinking that GC can not be developed in language the browser (and javascript) is built in is a bit naive (not to mention GC is a complex solution for simple non-problem, I would rather use malloc/new and free/delete + destructors than relying on Terminator Skynet ripped AI doing this really simple task - tribute to java and inability to free memory when needed! Anyway with each tab running in separate process, system will take care about memory leaks ;) ) while the runtime - the last time I checked, the CDNs were serving javascript libraries over mb in size and I really see no problem for them serving python runtime, while for c++, the runtime can be the browser itself and even if you pull in libc or proxy to the existing browser functions, this can be really, really small. Believing that code, that was designed to be human readable (as js), can be shorter than the opcodes doesn't really fit here.
I have heard this runtime considerations before but they are taking into account that someone will run webassembly compiled JRE in browser (and I am sure that right now, there are some freaks trying to achieve that). But there is still good old C++ (or Rust) not as productive as scripting languages but this is just due to much less open source "technological stack" (or some might argue, tribute to low quality of software today, "technological garbage") rather of not beeing capable of beeing competitive.
I think that the coolest trick that web based technologies pulled out was to convince the world, that the whole GUI needs to be primitive, simplistic, as they were unable to create something that desktop applications were doing for decade (speed/size considerations) and it might just happen that we will return back to owner drawn controls, where you wont be able to make distinction if app is running locally or in browser (no, I don't mean Electron, pun intended). There js will be unable to compete.
Anyway, push for webassembly is not here as corporations want to do something good. They want to push all computer users into old mainframe scenario, where you would have to rent space and cpu in a cloud and have just dumb terminal and javascript has hit its limits to replace desktop environment as it is, even with Windows Metro look (another simplification of GUI, done for mainframe scenario, Windows 365 are not far away)
Javascript was usefull in era of simplistic web pages as a small hack into html, but for next step we need something more and here there are other languages that can offer much more but are now limited to running in backend as they don't have browser support. But this will change with webassembly.
Runtime size depends on a few things. The biggest is JIT vs native. If you're willing to dedicate the time to making (or interfacing with) a completely native compiler, then the runtime penalty isn't that large. In contrast, any halfway decent JIT is going to be several MB of code (and unlike an image, has to be parsed and executed -- potentially on slow phones).
In both cases, the GC issue is non-trivial. LLVM has finally started to make performant GCs possible. Wasm (to my knowledge) doesn't have similar capabilities and guarantees (I suspect the are actually impossible with untrusted GC code). The only viable solution IMO is the addition of GC primitives and hope that your particular language maps well on that specific browser's GC.
I care less about the performance benefits of web assembly than the fact that it will open browser/cross platform scripting to other languages and I’d be curious to find out if we are still talking about JavaScript in 10 years.