Now Reading
The JavaScript Ecosystem is Delightfully Bizarre · Fly

The JavaScript Ecosystem is Delightfully Bizarre · Fly

2023-05-11 05:38:43

A landscape vaguely inspired by Salvador Dali's The Persistence of Memory including a melted baloon clock, craters, a disembodied hand, mountains, and a JS logo in the sky
Picture by Annie Ruygt

Be aware, I am not saying that JavaScript is bizarre, although it definitely is weird. However that is not the purpose of this weblog put up.

Bear with me, as an alternative of beginning with how JavaScript ecosystem is bizarre, I will begin with why the JavaScript ecosystem is bizarre.

Historical Background

Less that 10 years ago, JavaScript sucked bad. It had no imports, no classes, no async, no arrow functions, no template literals, no destructuring assignment, no default parameters, no rest/spread parameters. And the environment it predominately ran in, namely the browser’s DOM, sucked too. JQuery made it suck much less. It nonetheless sucked, however was — at that cut-off date — comparatively sane.

Bundling JS to run within the browser was the primary signal of weirdness. In that course of you’ll additionally need to each decrease and tree shake the supply, and maybe even code break up. Typically the method concerned studying quite a lot of JavaScript sources as enter after which producing a number of JavaScript sources as output. This meant that the code you had been executing wasn’t the code you wrote. Sourcemaps helped.

Then CoffeeScript got here alongside. As an alternative of writing in JavaScript, you’ll write in a language which was compiled into JavaScript. This can be a bit totally different than languages like Elixir and Kotlin which compile into the identical byte codes as one other language, CoffeeScript truly compiles into the opposite language. C++ began out this fashion.

Then got here ECMAScript 6 in 2015. JavaScript improved quickly within the subsequent few years. This finally largely displaced CoffeeScript, however introduced a special drawback: for some time the implementations weren’t maintaining so transpilers like Babel got here alongside that compiled present and future variations of JavaScript into older variations of JavaScript that ran on supported environments. At the moment esbuild is quickly rising in reputation as a Javascript bundler/transpiler.

Alongside the way in which, emscripten got here alongside which compiled precise machine code right into a subset of JavaScript, although lately the brand new goal for this software is mostly Wasm.

Currently the tempo of innovation in JavaScript has slowed, and JavaScript implementations are doing a greater job of maintaining, so you’ll assume that the necessity for transpilers could be waning, notably on the server facet the place there isn’t any want for bundlers. However that is not taking place. And the rationale why is an fascinating story.

Nobody Writes JavaScript Any More

OK, the title above is clearly hyperbole, but I’ll describe a number of the many ways that people aren’t writing JavaScript any more.

If you write a Rails application, you write it in Ruby. If you write a Django application, you write it in Python. Phoenix, Elixir. Lavavel, PHP. Rails gets a lot of flack for doing magic using meta-programming, and Elixir has macros, but all of the above stay within the boundaries of what can be done by the language.

JavaScript, however, is different. While it nominally is standardized by EMCA TC39, if you’re utilizing a well-liked framework like Next.JS, Remix, or Svelte you’re not coding in ECMAScript as standardized by ECMA TC39. 4 examples:

  • As soon as upon a time, almost 20 years in the past, the ECMA committee standardized E4X that enabled XML to be handled as an information sort. This misplaced favor, received deprecated and archived. Years later what as soon as was Fb (now Meta) had an identical want and invented JSX. It differs from E4X in that it compiles into JS.
  • One factor that ECMA TC39 has by no means standardized is sort annotations. Undeterred, Microsoft did it anyway with TypeScript. It, too, compiles into JS.
  • Svelte has their very own compiler that even deliberately misuses the JavaScript label syntax to allow marking an announcement as reactive.
  • It would not cease there. When a bundler/transpiler encounters an import assertion, they do not essentially presume that the file being imported is JavaScript and even any of the variants talked about above. If configured correctly and also you need to import a CSS or PNG file, it should happily do so for you.

I discussed earlier that Rails will get plenty of flack for its use of meta programming. No person bats an eye fixed at any of the “abuses” of the JavaScript language talked about above. The JavaScript ecosystem is a Large Tent get together.

“use Server”;

The latest abuse of the bundler is by React Server Components (RSC). First demoed with express, it’s now adopted by Next.js.

What “use server" and "use shopper" do, apart from being a sound JavaScript statements that do completely nothing, is change the which means of the code that follows them. This has gotten blended opinions, however in my thoughts may be very a lot within the spirit of "use strict"which additionally modifications the which means of the code that follows.

Whereas JSX typically compiles to JS, the Server React DOM APIs allow compilation to HTML. RSC goes a special method, and compiles right into a stream of tagged JSON. That is all very clear to you, however what it does allow is a different style of programming. One that many are comparing to PHP and even Rails:

It isn’t clear to me whether or not these comparisons are meant in a constructive method, however I’ll say that from my perspective it’s a excellent factor.

From a fly.io perspective, RSC enabling an Update (Refetch) Sequence may be very a lot of curiosity. We have all the time been particularly shiny for frameworks that profit from geographic distribution, like Elixir’s LiveView, Laravel’s Livewire and Ruby on Rail’s Hotwire. We wish these sorts of frameworks to succeed, as a result of the higher they do, the extra useful we’re. Now we are able to add React’s RSC to that checklist.

Returning to the subject at hand, the truth that such a characteristic is just made doable by way of cooperation with bundlers — an announcement tantamount to saying a change to the JavaScript language itself — is profound and, dare I say it, pleasant.

See Also

Another Dimension

Dan Abramov gave a talk at RemixConf entitled React from Another Dimension:

In Dan’s talk he imagines an alternate universe in which React was first implemented in the late 90s on the server and still managed to converge to where it is today. During the talk he launches a Windows 95 emulator and runs Internet Explorer (specifically, IE6) with React. He even manages to get nine out of ten steps working using that operating system and browser combination.

The mind bending parts of this presentation are where he first utilizes use server to implement a client side form action, and then later launches a client side alert from the server using use client.

And he closes by saying that this requires new generation routers and new generation bundlers.

And to think all of this is made possible by the fact that the JavaScript you write not only isn’t the JavaScript you run, but under closer examination isn’t even JavaScript at all.



Source Link

What's Your Reaction?
Excited
0
Happy
0
In Love
0
Not Sure
0
Silly
0
View Comments (0)

Leave a Reply

Your email address will not be published.

2022 Blinking Robots.
WordPress by Doejo

Scroll To Top