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...
For further actions, you may consider blocking this person and/or reporting abuse
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 :)