DEV Community

Why is Isomorphic JavaScript not longer talked about?

Andrei Robu on July 29, 2020

I'm posting this question because I've been away from web development for a few years and, back then, Isomorphic Development (the idea of running t...
Collapse
 
khrome83 profile image
Zane Milakovic

I don’t agree that it’s common place. Many things don’t use this. But when people want to do this, they reach for Next, Nuxt or Sapper.

That being said, after using all three, I am moving further away from it being a good idea.

  1. Many front end things don’t work on node. Try making a isomorphic app without bailing out of google maps.
  2. You still end up with server vs frontend. Next originally didn’t have that clean of a seperation and has more to making it clearer in the preload lifecycle.
  3. Harder to debug.
  4. Arguable slightly larger bundle on client. Some server code leaks. Period. Even if it’s behind a conditional.
  5. Much higher complexity. Trade off is we can use component based development.
Collapse
 
arobu profile image
Andrei Robu

That's a very comprehensive answer :)

Ok, so people either don't do it - because of these difficulties - or when they do they reach for a tool that provides this.

Collapse
 
khrome83 profile image
Zane Milakovic

I actually think people don’t do it, because it’s difficult to do in general, even before you get to the trade off and side effects. Hence the use of tooling to solve it.

Next, Nuxt, Sapper are great products. Though Sapper is very much weaker in term of features and maturity.

But the other trade offs are kind of ignored.

I think it’s a great concept for DX when it works and things work well. But users do not care. And the extra complications can lead to more bugs and less desirable outcomes.

That being said. Keeping a frontend and a backend code base seperate can also, because you may arguable have more code. Every situation is different. I like to start with the needs of the user experience and let that guide decisions.

Thread Thread
 
arobu profile image
Andrei Robu

So then the problem is not "solved", it's still a challenge and whether or not it's worth it can only be decided on a case by case basis 👍.

Thread Thread
 
khrome83 profile image
Zane Milakovic

Yeah. It’s better and can be worth it for sure. But it can make things more complex. Your really have to go in and do things the way the tooling allows.

Collapse
 
vonheikemen profile image
Heiker

Or is it no longer talked about simply because it is now commonplace and no longer a novel idea?

This. I guess it's not that impresive anymore.

These days I believe the focus is more on "server side rendering", is kinda the same idea but this one has a focus on frontend frameworks. Basically, some frontend framework can "render" your view on the server.

Collapse
 
arobu profile image
Andrei Robu

Great, this has been on my mind for a while so it's nice to know now.

Collapse
 
cullophid profile image
Andreas Møller

Frameworks like next is, Gatsby and angular handles this for you, so there is not really any point in talking about it specifically. but when people talk about SSR or SSG they are often talking about isomorphic/universal js

Collapse
 
imkevdev profile image
Kevin Farrugia

I believe it is still very common and on almost all large project that I have worked on, it is introduced at some point (ideally from the start, but more commonly later on once the performance is not satisfactory).

I think the difference between "back then" and now is that before the focus was on re-using your JavaScript code, hence the emphasis on the word isomorphic. Usage of Next.js has grown significantly, as have static site generators, and even the newest frameworks on the block (such as Svelte) have server-side rendering an integral part of their product.

So imo, the "buzz words" have changed because the motivations have changed, but the end result is the same.

Collapse
 
avalander profile image
Avalander

Well, it depends on how much isomorphism you expect. Of course you can use libraries like ramda both in the backend and in the frontend, and you probably want to run the same form validations in both places, so that code can be shared as well. Besides that, why would you want to run the same logic in two places? A task seldom needs to be run both in the frontend and in the backend, so why would you need to have the code in both places?

Collapse
 
arobu profile image
Andrei Robu

Fair enough, I can see how it can be a spectrum.

The example of doing isomorphic form validation is a very good one.

The other one I had in mind is that after rendering a page on the server-side, we may need to still have some client-side interaction, which may be dependant on some more complex logic and that we don't want to duplicate that between the client and the server side.

Collapse
 
akashkava profile image
Akash Kava

Another reason being, all business is moving to Apps, before mobile apps, browser was the only client running web based business application. Mobile web browsers are too slow and very buggy, so more focus is now on developing apps. With Web Assembly on the way, HTML+JavaScript will be replaced by some different front end that runs on both client as well as server like ASP.NET's Blazor.

Still JavaScript is great but HTML is broken, you still cannot expect your html to render correctly without using tones of CSS on variety of different flavors of browsers. This was always and is still pain. New browsers try to unify this but people with old computer/old phones, can't access new unified features.

Also with rise of AR/VR and Voice/Video communication, mobile web browsers lack cutting edge support for new kind of business communication, so we are more focused in making apps. This makes isomorphic JavaScript obsolete. As we will only use web to display features of app and all great part of code will be in the app.

Collapse
 
chrispardy profile image
chris-pardy

We have an internal library that is intended to be use isomorphically however what is there are things that can be proven "right" with unit tests. Those are things like functional composition helpers, and math functions. The key is that there is no business requirements. Where we have cases like form validation it tends to be that on the frontend the validation is much more complex since we're trying to provide actionable feedback whereas on the backend we can just reject the input. The cost of trying to share code and having the two coupled explicitly is not really worth it compared to a looser coupling where both the frontend and backend can deploy independently.

Collapse
 
qaismakani profile image
Qais Makani

I agree with the comments here. The idea is that if you're using fullstack JavaScript, code sharing, especially for utility code should be a given.

Collapse
 
pentacular profile image
pentacular

Isn't 'isomorphic javascript' where es6 modules naturally leads to?

The problem is all of the legacy cruft which requires packing.

Collapse
 
zilti_500 profile image
Daniel Ziltener

Well, why would any serious programmer want to run JavaScript on the server? It is a frontend language. But really it isn't a "new" concept anymore, I do it daily with Clojure :)