Since the time WebAssembly started gaining traction, a question has arisen among the developers: Will it put an end to JavaScript? Whereas, some ...
For further actions, you may consider blocking this person and/or reporting abuse
I disagree. Javascript as such will of course stick around in the same way that other languages seem to stay relevant as well. But there will be other options and those options will be operating on a completely leveled playing field. You won't have to use it because there are things that you can't do without it. A lot of people will choose not to. Even so, some might still prefer Javascript in the end.
However, what is going to change is that it is first going to lose its special status as the only language usable for frontend development. Then once people are using many languages on top of wasm, it's status as a special language with dedicated browser support will also be up for debate.
Right now it is special in the sense that the runtimes in browsers are specifically made and designed and optimized to run javascript. These runtimes have now been modified to also run wasm. Very soon that will be the primary thing they do. My prediction is that eventually somebody will figure out that javascript interpreters run perfectly fine on top of wasm and that there's no technical need whatsoever to have all these complicated bits and pieces around that are not related to running wasm code.
It's not like javascript is particularly fast. In fact the main early usecase for wasm seems to be not having to use javascript for things that need to be fast. In other words, people will start running javascript on top of a runtime that ships as wasm; in the same way that you can run other interpreted languages like python in wasm.
At that point browsers will know how to run wasm code and everything else just ships as wasm. Javascript will stop being special. If it needs to be fast, people will ship something precompiled as wasm. If it needs to run on old (pre wasm) browsers, they'll still use javascript. If they want to run a particular flavor of javascript, they'll just bundle their own wasm compiled runtime and not wait for all four browsers to be updated. It will be just yet another thing that you run on top of wasm. Transpilation will no longer be necessary if you can ship your own runtime.
Interesting, but to be clear. How much JavaScript do you really write? You do not have it on your CV? And can you list some sites you have made with JavaScript and other langs? I mean your reply seems common to someone who has long hated the language and has not used it in a real professional way. Just so I can calculate your prediction plus your bias toward "something else" in this case WASM. What is your real understanding of JavaScript... and please do not start parroting types and JS is not a real language and all that. Just tell me if you have made any good apps with it? Maybe even ones I can see. - regards.
@chad A lot more lately than I care to advertise on my CV because I'm not planning to be a full time front end developer. I wrote a couple of tens of thousands of lines of JS and typescript in the last six months for inbot.io. The front page is react and not done by me but the application linked from there was rewritten completely by me. It's a mix of typescript and javascript and uses a small framework called redom. I'm at this point pretty familiar with both languages and have migrated a lot from one to the other.
To give you the context; we used to have a front end developer and I took over his tasks end of last year. As we had some significant new requirements, I ended up touching and modifying large parts of it; converting most of it to typescript; and developing some pretty significant new features from scratch. The typescript conversion is still ongoing and has been totally essential for me to get a grasp on this code base. Refactoring other people's Javascript is just not a thing and when tests are also not a thing, you basically are forced to slowly reverse engineer what everything does. This is extremely painful in JS. Lets just say that I learned a lot of interesting javascript hacks that I would argue are seriously misguided by picking them apart and trying to figure out WTF was the intention before rewriting in typescript.
And you are right, I'm not particularly liking either language but you'd be wrong to assume I can't work with them. Typescript particularly, is actually fine and I wrote many thousands of lines of Javascript before switching to that.
But if you know other languages like Kotlin it kind of feels a bit messy and limited. It sort of gets you part of the way to a better language but not all the way. Part of that is just because they want all JS to be valid TS, which just means you are stuck with a lot of legacy.
Typescript adoption in the industry is unprecedented. I've never seen anything getting adopted this quickly. I've seen numbers suggesting that well over half the new projects are typescript now. It's for a good reason because Typescript indeed gets you types and better tools.
IMHO, if you are doing Javascript instead of Typescript at this point, you are simply doing it wrong. I've been fixing a lot of very obvious type errors as part of converting code to typescript. IMHO that's a category of bugs that is simply inexcusable in modern development. JS apologists seem to be increasingly on the defensive when it comes to this. You see the same in other dynamic languages that are also moving to stronger typing (e.g. Ruby and Python).
On the WASM front there are a few blocking issues like e.g. garbage collection still being in the process of implemented in browsers. ETA for this seems to be 1-2 years max. Despite this, you can run e.g. C# with Blazor (brings its own GC), Rust with several rust specific frameworks (no need for GC in rust) and a few other things. Google just released Google Earth as a WASM application.
Right now the limiting factors seem to be that it is mostly quite early. Despite this you see some efforts to completely bypass the js/npm ecosystem in several language communities targeting WASM. This is kind of the point. WASM is a runtime for people who'd rather not use Javascript. It's not going to be limited to just the stuff that JS is too slow to do.
E.g. the Rust people are pretty serious about doing everything in Rust. If you are doing Rust, you'll not have a lot of patience for languages like Javascript.
Similarly, C# people won't have a lot of appetite for javascript either when they are doing stuff with Blazor. The trend is pretty clear: these are very young projects but there seem to be lots of people interested in driving them.
I have good hopes for Kotlin and Swift in this space. They are already quite popular with frontend developers and both have llvm based compiler tool chains capable of producing WASM. This won't happen overnight but it is already starting to happen.
@jilles - that is a thoughtful and educational reply. And in turn, I can see that you have carefully thought about why JavaScript is not doing the best job you could hope for. 20 years writing javascript, I cannot say my code did anything special beyond doing the expected job. I can see the complexity and need growing for ever more modern approaches to building apps for the web. Many years ago, I saw middle and backend tier developers whom looked down on javascript and frontend web developers come over to writing javascript.
As the stack (in many cases) began to shift further toward "the client" and to stay relevant, and have work, many of these long time software programmers began to move into JavaScript and essentially the front-end, and javascript moved to the middle and backe-end. And now here we are, folks still seem to fall into camps.
Front-end development is just more difficult than backend development in some ways, and targeting multiple browsers as platforms with the same code base is just plain hard to do, or at a minimum requires real dedication to the work at hand.
Making multi-modal applications requires mastery and dedication to make a great web application and I get the inclination that the industry will always be chasing a carrot, even when it had something great that almost matured to be what was best for the expected outcome for our web.
Let us see how this new future for WASM evolves. To give some more context, I started my career 25 years ago building print layouts with tools that laid things out perfectly on the screen, and as the web evolved, so did my web coding. To share more, I have long been challenged with long hours making things pixel perfect with modern approaches, but I always succeed at the task.
I have trusted people, who swore the new ways would solve what seemed taken for granted in the digital print industry to no avail. Hence why I am seeking out mentors and masters in WASM. I like c# and what I have seen from Blazor so far. I make desktop apps and browsers with c# for automation often. I also make desktop hybrid apps with electron.js. I am open to the better future you describe and finally will close this reply with thanks for being so detailed and clear in your reply, and I look forward to more opinions from you and the community in the future. Sincere regards Jilles!
The writing will be on the wall for JavaScript as soon as webassembly gets direct access to the DOM. At first it will be slow but then some one will write tools to automate fundamental libraries like Date and time, and localisation to webassembly. Better typed checked languages without the need for transpilers will ensure JavaScript being used mainly for legacy code.
WebAssembly is the furture of all business web application development. I am pretty sure. Especially for business applications which has huge front end functionality. Frameworks which compile code into WebAssembly like Blazor can save about 40% development time and this is major fact for choosing this framework. You can save your development time and save customer costs. Companies, which stay in the past and continue development in Angular, React or Vue will be slower and more expensive than their competitors over time. For simple web pages, there will be always Javascript. There is no big advantage for simple web pages to use WebAssembly or frameworks which are built on WebAssembly.
I kind of lost your point when you started using percentages without real data? Do you have data tha backs up the 40% number?
+1, would be very interested in seeing numbers for this. It's my experience that developing in all these WASM languages takes way longer than JS and there's no way there's going to be a 40% increase in productivity without solid frameworks to handle the heavy lifting.
You mention Blazor - have you actually used Blazor? I honestly don't know a single .NET dev that likes Razor (and I know a lot), let alone Blazor.
There's a proposal on WASM module integration which should make your life easier: github.com/WebAssembly/esm-integra...
You still won't get rid of JS
WebAssembly is going to get a lot better in the future: WebAssembly’s post-MVP future: A cartoon skill tree
JS/TS has the biggest development community and ecosystem in the world, by far. Although other languages (especially Rust IMHO, which is awesome when used in conjunction with Parcel - zero config FFI in a nutshell) will make the web even more awesome, modern JS/TS won't go anywhere - in fact, with more and more Apps going full PWA (or JAMStack) I suspect JS/TS to grow even more fastly in the future.
Finally, someone who is not "hoping" and "waiting" and who basically is correct. Thanks for being the voice of reason. It is usually folks who have not made any real modern web apps with javascript that seem to say Javascript will die.
Web applications are a complex but important part of any business. Having a secured and responsive web app can increase customer and employee engagement to multifold. These applications are commonly used in communication with customers, collaboration with employees, secure storage of data, and providing data and information to management. We at Hakuna Matata Solutions is an experienced web application development company that has been helping companies achieve their full potential in their respective field.
Ok JS is not going to be displaced by WebAssembly, what about the future of languages that compile to JS, for example elm? Elm to JS and WebAssembly seems like a great transition to event-driven systems.
Really the only thing? Do you have experience making Rich Internet Applications? Do you recall compiled binaries for the web? They ran in ActiveX, Flash and Silverlight. Your advocation for WASM, which I welcome by the way, seems to point to a holy grail that does not yet exist? Please share more. - regards.