DEV Community

Cover image for JavaScript vs JavaScript: Round 2. Fight!

JavaScript vs JavaScript: Round 2. Fight!

Ryan Carniato on September 17, 2021

After I finished the first article I wasn't sure how long it would be before we'd have enough topics for the next round. But given the continuing a...
Collapse
 
siddharthshyniben profile image
Siddharth

Awesome post! I wish i could find that article you were talking about – It sounds like an awesome read!


It would be interesting to see a truly runtime-less JavaScript framework with a significant feature set. But these don't really exist [...].

Guess what: I'm experimenting with building such a framework!

Collapse
 
ryansolid profile image
Ryan Carniato

The closest I've seen is Prism. It isn't completely runtime-less in general but they had a cool webcomponents demo that essentially was since all stateful updates in the simple example were simply handled by getter/setters on the element.

Collapse
 
peerreynders profile image
peerreynders

So which is the truer JavaScript?

In Clojure I came in contact with REPL-Driven Development which coming from a C/C++/C#/Java background was absolutely foreign to me (apart perhaps from working in an SQL shell).

Similarly with JavaScript, at least on desktop browsers, through the Web Developers Tools console one can interact live, directly with the browser and the page or even just simply locally throw together an index.html to play around with some ideas.

Sure, you can go to the TypeScript Playground to play with some TypeScript but that doesn't have access to the browser; sure one can use services like CodePen or CodeSandbox but one typically has to figure out the idiosyncratic details of their UI and platform.

Yes, it's not that difficult to "just" download create-react-app (if you're comfortable with npm), though but, gee …

(I typically just use Preact).

Point is, having an incredibly low barrier to experimentation is invaluable (I assume that's why framework websites often have playgrounds associated with them).

Sure, tooling is bound to aggregate around products as they move closer to production but it can be really useful to have an extremely low barrier to just getting started.


Well, it just means we have a new framework.

I think Ramus Lerdorf summarized it well:

They all suck. While they all suck, everyone needs a framework. What everyone doesn’t need is a general-purpose framework. Nobody has a general problem. Everyone has a very specific problem they’re trying to solve, and the general-purpose framework, while it can solve it, it usually solves it in a way that you get so many other things that you don’t need that ends up being done on every request.

People were worried about vendor lock-in with application servers, now they are worried about vendor lock-in with cloud service providers , meanwhile mindset lock-in is in full swing with frameworks. I can't even imagine how irritating it must be for authors of the "other" frameworks, to constantly have to explain themselves in terms of React — when React isn't even of the web — in fact it was created to de-emphasize the web.

Perhaps it's developers who need to be "framework-agnositic". The problem is that adopting any particular framework (of any kind) represents a significant investment of time and effort, naturally pre-disposing one to fall victim to the golden hammer rather than pick the right tool for the job. The typical "enterprise response" is to settle on one "batteries included" solution and standardize on it — however that often leads to added baggage which can typically be absorbed in the enterprise space but often not so much on the public internet.


Know what else is composable? Components.

Mmm — that is highly context dependent.

The wider and more complex the interface of a component (in the general sense) is, the less composable it is - a component is an object after all.

Well there is something incredibly powerful about the framework provided primitives and the end user creations being the same.

Joe Armstrong:

This adheres to our general principle - we do not provide built-in mechanisms, we provide primitives with which mechanisms can be built.

(primitives in Erlang: spawn, send, receive, make_ref, etc. — the (composable) mechansims are built with functions, tuples and lists.)

So perhaps some framework "primitives" are just poorly chosen?

From that perspective React would already be a mechanism on which other custom mechanisms are built.

If you've used <For> you know how to use <PaginatedList>.

Components (in the React or JSX sense) can require and support a vastly varying set of props (and children) depending on their role.

For example <div> plays are very different role from <CountContext.Provider value={value}>{children}</CountContext.Provider> and require a very different understanding to be used effectively. From that perspective the composability of "Components" is purely a result of by design being constructed to collaborate within and through the component tree via an implicit interface. That's OOD 101.
Design Patterns: elements of reusable object-oriented software; 1995, p.18:

Program to an interface, not an implementation.

And implementing framework specific types is par of the course with frameworks.


I am talking about ones that make heavy use of compilation to do work ahead of time.

In some sense compilation is a responsible means of providing "developer experience" because it can create value without deferring the cost further downstream. Often "run time is cheaper than developer time" is the justification for deferring cost further downstream but certain forms of compilation can help to mitigate that.


Progressive enhancement is a consideration like Accessibility.

I think to some degree that is only part of it; Everyone has JavaScript Right?

  • Acknowledge the limitations set by the laws of physics — the web is a distributed system (The fallacies of distributed computing).
  • Recognize that the web simply doesn't have the same slack that desktop and native have had in the past to cover potential inadequacies of the development process. Some practices that worked there simply cannot be tolerated on the web and shouldn't be expected to work.
  • Respect the user's resources and don't take them for granted: connection quality, bandwidth and speed; compute power and battery charge.

i.e. don't design an application that will only work under optimal conditions; deliver functionality with the minimum amount of HTML/CSS and JavaScript to engage the user as quickly as possible, then carefully and judiciously download and cache additional capabilities.


And part of that is Multi-Page App Frameworks are dominating innovation in this space given Single Page Apps are less optimizable in this way.

Putting a different spin on this: SPAs introduced monoliths to web applications.

The history of SPAs seems to go back to about 2003; meanwhile in 2005 microservices became a thing, largely leaning on the idea of a bounded context from Eric Evans's Domain-Driven Design in 2003.

In 2015 I vividly remember running into blog posts like Mixing MPA and SPA: worst of both worlds.

Then Micro Frontends made an appearance in 2016 - which in my judgement completely failed to take the nature and constraints of the web into account - especially when claiming the "benefit" of micro frontends being able to each use their own distinct/separate UI framework.

Perhaps MPAs will become the real "micro frontends" — each page having highly focused capability which can be downloaded relatively quickly while sharing resources with other pages from the site via Service Worker, Indexed DB, and BroadcastChannel (SharedWorker would be nice).

Collapse
 
rizkimcitra profile image
R. Maulana Citra

Holy s**t bro, I read till the end of the article, your post is awesome, i would like to read more about this stuff next time!

Collapse
 
aecea profile image
Duc-Thien Bui • Edited

bostonmagazine.com/news/2021/09/14...

“But there’s so much stuff to do,” he continues. “There’s so much work to do now trying to clean the Web up. For Solid, there’s a serious amount of work. There’s never very much time to sit back and go, ‘Oh, wow.’”

I would love to read your thoughts about this epic battle for the WWW as a whole.

Collapse
 
mzaini30 profile image
Zen

Where's part 3? 😅

Nice article....

Collapse
 
ryansolid profile image
Ryan Carniato

Hah.. It's only been a couple days.. need a few more things to gather up. MPA mode maybe. Seriously this year has been ripe for these sort of topics. So much new tech coming up in SSR, rebirth of MPAs, and Svelte's philosophy permeating the frontend hitting a critical mass.

Collapse
 
mzaini30 profile image
Zen

Now: MPA is comeback! You can build website with 0% JS!

Later: Today, you can build website with 0% HTML 😅

Collapse
 
jonrandy profile image
Jon Randy 🎖️

If you like Svelte, you should take a look at RiotJS - been around a lot longer - it's on version 6 now and seems to have influenced Svelte a lot

Collapse
 
metammodern profile image
Buniamin Shabanov

I read your posts only for memes.

Collapse
 
swise191 profile image
Swise-Haymann

Love your Articles Ryan.. 👌⚡❤️

Collapse
 
koire profile image
Koire

Love the mention of hyperapp! Wish I could get more traction with it at work