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 the same code on the server as in the browser) was in vogue and widely discussed, with many articles were being written about it online.
An example is this article, Isomorphic JavaScript: The Future of Web Apps, which predicts that Isomorphic JavaScript would become more popular:
As more organizations get comfortable running Node.js in production,
it’s inevitable that more and more web apps will begin to share code
between their client and server code.
And this article, Why Everyone is Talking About Isomorphic / Universal JavaScript and Why it Matters, explaining why Isomorphic JavaScript can be useful:
In addition to re-using templates, developers can also re-use the same
libraries and utilities on both the server and browser, further
reducing the need for excess code. Libraries like Underscore.js,
lodash, Request, and SuperAgent are hugely popular for this reason.
Having the same library on both the server and browser allows for
better development and code reuse which leads to happier software
engineers and less time spent maintaining the code.
Now that I'm coming back to web development, I'm picking up where I left off and catching up. This idea captivated me and I'm sure I'm not the only one interested, yet it seems this is no longer discussed and that there are no or few recent articles about it. Why is this the case?
I'm hoping you could answer below with your experience.
Did experience show that it is not worth the hassle?
Or is it no longer talked about simply because it is now commonplace and no longer a novel idea?
Top comments (16)
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.
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.
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.
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 👍.
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.
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.
Great, this has been on my mind for a while so it's nice to know now.
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
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.
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?
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.
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.
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.
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.
Isn't 'isomorphic javascript' where es6 modules naturally leads to?
The problem is all of the legacy cruft which requires packing.
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 :)