I'm not sure if there's ever been a language more loathed, yet so widely used, as JavaScript.
I'm not of that camp. I quite like JavaScript. Its quirks, its flaws. How it somehow built upon Scheme yet was destined to be the most pervasive programming language.
JavaScript was designed to be a companion. A scripting language to perform menial tasks to assist small pieces of interactivity on the page. The language of the web.
But the web has grown well beyond what it originally was. It encompasses all manner of experiences and devices. From computers, mobile phones, televisions, and watches to all manners of IoT devices. From the simple content site to the immersive virtual reality video game.
And JavaScript has come along with it.
Phenomenal Cosmic Powers, Itty Bitty Living Space
The one thing the web foundations have repeatedly shown us is how critical the network is as a resource. Most programming is concerned with memory or disk speed, but the web is always concerned with the network. This, along with being a free-for-all of platforms and really the only available option, has led JavaScript to develop most peculiarly.
While JavaScript by any measure is an interpreted dynamically typed scripting language, it now is a transpiler, a melting pot of DSLs, and a whole toolchain. The machine of JavaScript has long replaced the soul. It needs to be everything to everyone, yet be imperceptibly small and resource-light.
The starkest thing I see when looking at how we develop applications in JavaScript is that ultimately no matter how great the potential, catering to the lowest common denominator on device capability and network speed still drives the conversation. It is an inescapable truth. The law of physics we must obey.
The Role of JavaScript Frameworks
It is not uncommon for a language or framework to aid developers in achieving the performance they desire. But what about deleting our own code? The most performance-oriented JavaScript frameworks are obsessed with allowing us to run less JavaScript.
JavaScript is probably more concerned with producing less JavaScript than anyone else. You see this when frameworks like Svelte or Solid are considerably smaller than Stimulus or even Alpine. You see this with all the focus from Marko, Astro, and Qwik on Partial Hydration. Even things like React Server Components reflect this concern.
We lean heavily into bundlers and compilers to strip out every bit of code we don't need. The goal is to optimize every last bit of execution in our templates. Create specific languages to better capture intent to make that all possible. We analyze our apps to break apart code that can only be run on the server from code that runs in both places. And we use that information to reduce data serialization costs.
We even leverage server-side rendering to inform how to reduce the cost of booting up the application in the browser, through newer concepts like resumability. Running the application on the server fills in the gaps compilation can't handle ahead of time.
everything OK babe? you’ve barely touched the newest JS framework03:32 AM - 04 Aug 2022
A new JavaScript Framework every week as the saying goes. A constant struggle to innovate and push boundaries. Background knowledge of never being satisfied with the status quo haunts this space. There is even a term for it. JavaScript Fatigue. Buried in the complexity of learning and of choice. And yet they continue to rise like an unending stream of the undead. Each building upon the remains of the past.
This isn't necessarily a bad thing. It is a sign that there is more work to do. If you change your perspective that the status quo is more a 4 out of 10 instead of an 8 out of 10, none of this is surprising. JavaScript fatigue is caused by reality missing expectations. Let's talk more about those expectations.
The JavaScript Paradox
We created the problems we are solving. Our desire for more interactivity and better user experiences. Not relying as heavily on the network. The wish to use a single toolset to build all manners of site or application for the web.
But it is more than that. We could take a backend language and sprinkle JavaScript over it, and for a time that might be alright. Mechanically that is all we ever wanted. But it is almost impossible to turn back the clock on the developer experience we've seen over the last decade. The ability to author things as a single application, instead of weaving our JavaScript through as a steadily growing, but unwanted, orphan on top of our server application.
If anything we get more and more benefits from reducing those boundaries between the front and the back. To the point that it isn't even that controversial to suggest using JavaScript full-stack is the best way to ship less JavaScript.
Another language runtime might make savings in the 10s of ms but when we talk about the impact we can make for the end-user on the destination device through leveraging using JavaScript on the server can be in the 100s of ms. It's an order of magnitude more impactful to the end user.
But admittedly it might affect your bottom line. JavaScript's sole purpose for existence was the browser and now we have brought it everywhere.
Are we Stuck?
Well, where I'm sitting, at least for now. This is a direct extension of JavaScript being the only language of the browser. WASM shows promise in some areas but isn't making a dent on the user interface side of things yet. There are inherent costs that it needs to overcome.
zack@zack_overflow
So I don't think perf is a super compelling reason to use a WASM frontend framework.
And that's also why rewriting React/Svelte/SolidJS/etc. in WASM won't really amount to significant performance gains, if any.16:34 PM - 27 Jul 2022
If the end user's device and network are on the critical path, optimizing for it may be the most impactful thing we can do. And if the best way to combat JavaScript is using more JavaScript, that's where we are.
I'm sure someone will point out server-driven architectures like LiveView or HTMX and those contain great approaches to reducing costs. They abstract some of the JavaScript from the developer to maintain a server-centric view. However, when you do want the interactivity in the client (for whatever reason, offline, etc...), when JavaScript is the only choice, well, JavaScript is the only choice.
That being said tooling for JavaScript has seen a move to Rust and Go (and Zig). There is a desire for more performance and ever more creative ways to leverage these to allow for an authoring experience that is all JavaScript.
In Search of a Silver Bullet
Don't get me wrong. You can always just build an HTML site and put some JavaScript on it as needed. This whole motivation comes from a place of wanting to scale the development of a single app mentality. This isn't every project's concern.
But I did find it interesting that in my search I found that there is more than one way the problem is being approached for low-end devices and networks. I think for those used to fast networks with only the intermittent interruption of something like the subway, it's easy to think about how to optimize for some base case without changing the equation.
eBay had a big year of performance optimization: bit.ly/ebayspeed ~ smaller payloads, smart prefetching & edge-caching had an impact.
For every 100ms improvement in search page loading time, they saw a 0.5% increase in Add to Cart count! ⚡️07:30 AM - 28 Jan 2020
Looking at how big international eCommerce like Amazon or eBay operates or services like Google Search handles things, are confirmations of that. Build small, build light, and smartly leverage the server to get the quickest initial loads and interactions. There are enough studies to show how that impacts revenue.
However, in China and some other regions where the internet isn't so consistent, they've adopted a completely different model. Mini-Programs which are a bit like PWAs that load into existing mobile apps as pluggable sub-apps. A sort of localized app store.
Instead of optimizing for initial page loads, they optimize on background data loading, to ensure the app can run as well as possible regardless of the network or device resources. Often bringing in more JavaScript to save future network requests is seen as extremely beneficial. What we have is a whole ecosystem of web applications in constrained environments not at all interested in leveraging the server.
If there is any takeaway, this isn't always so cut and dry. If there were a way to bridge the gap here it is probably still more use of JavaScript today.
Conclusion
This topic asks a lot of questions of us. Should JavaScript continue to eat into the backend? Are there better ways we can leverage other languages and platforms with JavaScript? Should we even be chasing after that unified vision of the web?
Or maybe the question we should all be asking is how did we let such a monopoly happen?
While you have infinite choices in how you build your websites and applications, JavaScript has a substantial leg up. So much so, that it is probably the best way to actually ship less of it to your customers. And to me, that's kind of crazy.
Latest comments (37)
Very interesting and thought provoking article. Well done
JavaScript is the proof of that we're in a "race to bottom". It's one of the top 5 worst programming languages ever created, yet still the by far most popular language.
Amazingly accurate comparison of frameworks/libraries in the picture! :)
wow that's a great article
I just want to mention htmx + alpine js as an alternative to write less javascript and give more power to your backend framework
In my opinion, the future is not SSR and not the current comprehension of SPA, but a kind of SPA that leverage the power of WASM / WASI.
I'd say SSR should be ended since the introduction of Javascript, Ajax and Flash Player plugin. The only justification for using server side rendering has always been the concern with SEO and compatibility with multiple browsers, but this is no longer a concern. Today Google can mine even information inside videos and photos. In terms of capacity, nowadays the browser is perfectly capable of solving 95% of Native App use cases.
Backend devs should focus on creating more advanced services and not on a combination of classic web and modern web.
Javascript will probably always be the most democratic language in the world, as well as Python precisely because of the characteristic of experimentation and adaptation. In both cases using a framework is a matter of choice, however the market continues to try to find a way to standardize what means to be a developer in certain language, which is probably good for selling courses and diplomas, but in our daily lives it doesn't add much.
You can do anything that is possible in the browser with JavaScript. If you don’t like the programming language use a transpiler. It’s ubiquitous and therefore here to stay whether we like it or not.
imho
:o)What (for instance) React does (and that's why React is great) :
--- allow us to do the job using a "minimal" amount/subset of javascript.
So, effectively, to a certain extent, in a certain sense, what (for instance) React is doing:
--- make javascript irrelevant (=it matters much less).
I'm glad WASM is here. Crockford says Javascript is old hat. I agree.
We didn't actively push the performance talk forward. It was born of necessity - the age of the internet has caused our attention spans to shorten (this is even researched - on average, the world's attention spans have gotten lower over the years).
Page loads are important. As your eBay example shows, even 100ms can make a huge difference in the human perception.
And yet, as times move forward, the human expectation also rises - we want bigger, better web apps, with more capabilities and we have gone so much in that direction that many web and desktop apps have become basically the same thing and provide similar functionality to what in the past you would only expect to see in a true application (think Google Docs!).
And with that expectation I just mentioned, came the ever increasing bundle size, which increases load times, which cause us to need to focus on performance more. It's not that we are performance maniacs - its that we have a need to catch up with the times and expectations of the modern tech era.
WASM is still a bloat! Wait for the major compiler to support the component model. Most of the compiler we have now only think about producing single efficient executable but not thinking about chunking which is very crucial in web app/page. It will take a very~long~time™ for WASM to be usable as JS replacement. If you need performance then it's better to bet on compute shader use-cases in WebGPU rather than SIMD computation in WASM.
As for mini-programs, WASM might be very viable choice as long as the company define the standard interface for rendering their custom UI component.
Just saying JavaScript literally changed my life, loathed is a strong word, maybe loafed because it gives me 🍞 bread
There is always a trade-off between performance and easy-to-write. More languages and libraries are created because both creators and developers want faster and easier development.
Just like you said,
And...
We've seen JavaScript and Python took off due to the biggest reason that they are easier to write than static typed languages. The same thing with the rise of React and other libraries wrapping JavaScript with easier use cases. Then functional components and React hooks...
Does using a React have a worse performance than plain JavaScript? Yes. Does WASM beats JavaScript in benchmark? Yes. But better performance certainly always leads to more complex code.
Python is built upon C. C is built upon Basics. We can write code in assembly language, but no one is doing that.
Besides from easy to write, the monopoly of JavaScript and its libraries is majorly due to the close fit with the web development use cases nowdays.
Libraries became popular because they make handling user interaction, state and backend calls much simpler. If we are still using Yahoo and other Web1 applications with little user interactions, we probably don't need these libraries.
Yes JavaScript and Python are invented as scripting languages and not invented for large scale applications at first. But we need to view them with the use cases we have now.
If the performance and stability is the priority of a large scale application, it's definitely helpful to switch to WASM and static typed languages. Same reason for TypeScript.
But the easy to write for the rest 90％ of medium to small scale applications is the priority. Combine with the MVP and lean product trends for millions of startups, they are definitely choosing JavaScript over others.
This is why I believe JavaScript and its libraries aren't going anywhere soon.
To me always remember " Everything impossible will be possible"😎👍🏽
The thing you have to have (JS) will eventually eat up all the competing things you would like to have (Ruby etc.).
This idea is expressed elsewhere in society as: «the tyranny of the intolerant minority», or «the most intolerant wins».