2 ms·

Except for the confusion about terminology the article has some good points. We had an idea a long time ago in the web dev world that we could run the same la

by tored 4y ago

Except for the confusion about terminology the article has some good points. We had an idea a long time ago in the web dev world that we could run the same language in the browser and in the backend. Basically reuse everything and save time. It think this is bad assumption to begin with. If I have a clean separation between frontend and backend, regardless if doing mostly server rendering or client rendering it is only one thing that makes sense to share, input validation code. Like what is the definition of a first name, last name, age, price, email address etc. That is the one thing that need to be in agreement between the frontend and the backend to be able to exchange data. But to share frontend and backend technology for only the gain of input validation seems like a heavy price to pay for little gain.

deepstack 4y ago
Being used server side JS since before NodeJS came along on JVM. I would say your assessment is correct (input validation) around that time. However React, Vue, Preact, Svelt, SolidJS (not to mention web components) changed that. We now have a group of people ONLY associated html rendering with those type of frameworks and components. So HTML rendering on the server side is pivoted to cater to those type of front end developer with 'Hydration'. The EJS templating type of rendering has being phased out. It is not good or bad, it is catering to what developers are use to.
dgb23 4y ago
That has not been my experience. Input validation or more broadly data integrity is just the first, obvious issue. There are things that can help with that like json-schema, openapi, graphql and so on, which solve some part of this at some level. Let's go for json-schema, which is the simple, focused data driven and pretty well designed. Great isn't it? But it doesn't stop there. You now have at least two libraries in different languages with different levels of support for the spec, so you need to settle on the lowest common denominator. That's just the validation part, now you want error reporting, which means duplicating logic again. You probably want to convert the schemas or at least the data structures they validate into something that your languages work well with, that's duplicated logic again. Then you also need to somehow pull them in, build them etc. which is duplicated tooling around your language environments. Now you have version dependencies of somewhat the same thing in two different ecosystems with different versioning issues. Whenever I said "duplicating" I really meant "solving the same-ish problem in two different ways", so "duplicating" is an euphemism here. It's a proliferation of accidental complexity and coupling. Isomorphic code is not just a 1:1 thing. It's not necessarily the same functionality that you maintain on both sides (like validation) it's _all_ the other stuff as well, unrelated in terms of single features. Aside from validation and data integrity - and the whole jungle of stuff that comes with it - you also need a bunch of fundamental data structures, network I/O, possibly routing logic if you're doing anything that's dynamic on the frontend and serves UX beyond just displaying text and images in a nice way. You want quick, optimistic feedback on the client, so you're coordinating more state and data, which means more duplication again. You might want to move stuff from the server to the client and vice versa, when you discover basic optimization issues. Isomorphic code is _leverage_ to a high degree from tooling to standard libraries to knowledge, familiarity and mastering a language and ecosystem as a programmer. If you decide to use a heterogeneous ecosystem you better have good reasons for it such as legacy code, specific powerful libraries and integrations you need to use or high expertise in a particular language that cannot talk to both sides.
- tored 4y ago
  Most of these problems stems from moving too much to frontend, making the frontend tilt over. If you keep more logic in the backend much of these problems goes away. Problem is that for every core concept moved to the frontend it still needs to exist in the backend, a representation of an article needs to exist both in the frontend and the backend, same for error handling, logging, authentication etc, but they are rarely identical, even if you would code them in the same language, because the frontend will always be a remote representation of what the backends implements. Thus the more you move the more you need to duplicate. Some views or components needs to be more interactive, true, but not every view, thus you solve the interactive part of those specific views or components in pragmatic way to minimize friction. One pragmatic solution is to use BFF, backend for frontends, where you have a specific API, both for reading and writing, for that component or view only. Now you can adapt those together to a better fit, including error handling. General and reusable (REST) APIs for driving a frontend is a bad idea, you should have specific APIs for each case, otherwise you end up doing asynchronous JOINS over HTTP. The next step to realize after that is that if you already have specific APIs for a components you can skip passing JSON all together and just return HTML, thus saving an entire JSON encode/decode roundtrip. JSON schema is trash btw, schemas does not fit JSON data well, structured data is better handled by something like XML. And what this shows is that using JSON for large data representation is a bad idea, but it is usually where you end up when doing heavy frontend.

by tored 4y ago

deepstack 4y ago

Being used server side JS since before NodeJS came along on JVM. I would say your assessment is correct (input validation) around that time. However React, Vue, Preact, Svelt, SolidJS (not to mention web components) changed that. We now have a group of people ONLY associated html rendering with those type of frameworks and components. So HTML rendering on the server side is pivoted to cater to those type of front end developer with 'Hydration'. The EJS templating type of rendering has being phased out. It is not good or bad, it is catering to what developers are use to.

dgb23 4y ago

That has not been my experience. Input validation or more broadly data integrity is just the first, obvious issue. There are things that can help with that like json-schema, openapi, graphql and so on, which solve some part of this at some level. Let's go for json-schema, which is the simple, focused data driven and pretty well designed. Great isn't it? But it doesn't stop there. You now have at least two libraries in different languages with different levels of support for the spec, so you need to settle on the lowest common denominator. That's just the validation part, now you want error reporting, which means duplicating logic again. You probably want to convert the schemas or at least the data structures they validate into something that your languages work well with, that's duplicated logic again. Then you also need to somehow pull them in, build them etc. which is duplicated tooling around your language environments. Now you have version dependencies of somewhat the same thing in two different ecosystems with different versioning issues. Whenever I said "duplicating" I really meant "solving the same-ish problem in two different ways", so "duplicating" is an euphemism here. It's a proliferation of accidental complexity and coupling. Isomorphic code is not just a 1:1 thing. It's not necessarily the same functionality that you maintain on both sides (like validation) it's _all_ the other stuff as well, unrelated in terms of single features. Aside from validation and data integrity - and the whole jungle of stuff that comes with it - you also need a bunch of fundamental data structures, network I/O, possibly routing logic if you're doing anything that's dynamic on the frontend and serves UX beyond just displaying text and images in a nice way. You want quick, optimistic feedback on the client, so you're coordinating more state and data, which means more duplication again. You might want to move stuff from the server to the client and vice versa, when you discover basic optimization issues. Isomorphic code is _leverage_ to a high degree from tooling to standard libraries to knowledge, familiarity and mastering a language and ecosystem as a programmer. If you decide to use a heterogeneous ecosystem you better have good reasons for it such as legacy code, specific powerful libraries and integrations you need to use or high expertise in a particular language that cannot talk to both sides.

tored 4y ago
Most of these problems stems from moving too much to frontend, making the frontend tilt over. If you keep more logic in the backend much of these problems goes away. Problem is that for every core concept moved to the frontend it still needs to exist in the backend, a representation of an article needs to exist both in the frontend and the backend, same for error handling, logging, authentication etc, but they are rarely identical, even if you would code them in the same language, because the frontend will always be a remote representation of what the backends implements. Thus the more you move the more you need to duplicate. Some views or components needs to be more interactive, true, but not every view, thus you solve the interactive part of those specific views or components in pragmatic way to minimize friction. One pragmatic solution is to use BFF, backend for frontends, where you have a specific API, both for reading and writing, for that component or view only. Now you can adapt those together to a better fit, including error handling. General and reusable (REST) APIs for driving a frontend is a bad idea, you should have specific APIs for each case, otherwise you end up doing asynchronous JOINS over HTTP. The next step to realize after that is that if you already have specific APIs for a components you can skip passing JSON all together and just return HTML, thus saving an entire JSON encode/decode roundtrip. JSON schema is trash btw, schemas does not fit JSON data well, structured data is better handled by something like XML. And what this shows is that using JSON for large data representation is a bad idea, but it is usually where you end up when doing heavy frontend.