5 ms·

Can't agree more. It's El Dorado for web developers. You might be able to write all your app code in Javascript, but the inputs and outputs are so different th

Can't agree more. It's El Dorado for web developers. You might be able to write all your app code in Javascript, but the inputs and outputs are so different that you never really avoid "if(isServer()) {...} else {...}". You can't contain that in a single file, either. It surfaces in the most unexpected places and gradually erodes the illusion of "universal," until you're never sure in which order or what environment your code is executed. You'll have pieces of code written and rewritten again and again and executed several times just to make sure it gets called in the exact moment, with the exact arguments you need, at least once. I spent many years in search of "universal" JS, and worked with many people who were convinced they had found El Dorado, yet always ended up in situations like I described, so maybe I'm jaded.

abritinthebay 9y ago
Apparently I’m working in El Dorado then...
- deleted 9y ago
  [deleted]
dbbk 9y ago
This is not the reality though... with React and Ember (presumably also Vue) there is one place where client-side only stuff happens, and it's in component lifecycle hooks. It's perfectly clean and makes sense.
- tboyd47 9y ago
  It was and is a reality for many people and was my very frustrating reality for quite a while. The concept of "client-side only" code that does anything more significant than animations (such as, say, modals) breaks down if you want deep linking, and deep linking requires full data reloading on every action, because how can you be sure the data is all there if you don't load it, and once you're reloading your entire state tree on every action you're already slower (not just in data transfer but in code execution) than the "traditional" client-server pattern, and if you have a UX team and any timeline pressure at all, you've already written yourself into several corners for UI bells and whistles, which unfortunately affect the server side as well now, not to mention being at least a major version out of date on several NPM libraries, and just another rewrite away from clean architecture, and so on...
- weego 9y ago
  So you have 2 versions of the code with a shared contract between the two. Isn't that exactly what the original criticism was, other than in this world your server and client both have packaged code that is likely redundant or at least not a clean abstraction?
  - Can_Not 9y ago
    We have one version of the client-side code and one version of the backend API code. The server-side code mounts the client-side code like a pure function for rendering on a user's first arrival. You can technically separate the SSR from the API if you want (might even be default in some places). "You have 2 versions of the same code" is a simple misconception from people who still think in terms of jQuery at best, at worst it's intentionally ignorant and misleading.
    - tboyd47 9y ago
      "2 versions of the same code" is not a very precise description. Either it's one chunk of code or two chunks, or one chunk that extends the other chunk in some way. What we ended up in my case was one chunk of code (server) that extends a shared chunk (server/client), with plenty of server vs. client branching inside the shared chunk, either on a boolean flag or the presence of some data structure that only exists in one environment. I have never seen the use case that many people flippantly claim is so easy, which is the "one chunk" concept, nor have I seen a chunk of server- or client-only code extend shared server-client code in a way I would describe as clean. Stuff tends to get messy when you have to deal with the space between the server and the client, like cookies, asset loading, or third-party services, or when you have to do fancy UX tricks. Then users who are used to "traditional" websites do things like refresh the page at weird times, click buttons more than once, load the app from the wrong URL, use the wrong browser, click things too fast, leave a tab open too long, and so on. And then, as others have mentioned, you have sensitive logic that needs to live only on the server for business reasons. Then the framework you're using moves too quickly or not quickly enough to support a browser feature you didn't know you needed until right now. All this stuff only comes in later, once the app meets the ground, and is rarely discussed in initial architecture meetings. The only way I could possibly see these solutions as cleaner than the old "two-chunk" way are if I were to automatically dismiss all those pragmatic concerns or consider them to be cleaner simply by virtue of the fact that they're different. It's frustrating to me because I see so much optimism on online forums about "Universal" JS as this earth-shaking sea change on the verge of happening, even though honestly it's been 10 years since NodeJS came out and first made Universal possible. It makes me feel a bit like an old fogey for throwing up my hands and saying, "Let's just let it go and stick to the original design of the web," meaning, two chunks. But that's the only way possible for me to deliver the real requirements I have on projects without driving myself crazy.

abritinthebay 9y ago

Apparently I’m working in El Dorado then...

deleted 9y ago
[deleted]

dbbk 9y ago

This is not the reality though... with React and Ember (presumably also Vue) there is one place where client-side only stuff happens, and it's in component lifecycle hooks. It's perfectly clean and makes sense.

tboyd47 9y ago
It was and is a reality for many people and was my very frustrating reality for quite a while. The concept of "client-side only" code that does anything more significant than animations (such as, say, modals) breaks down if you want deep linking, and deep linking requires full data reloading on every action, because how can you be sure the data is all there if you don't load it, and once you're reloading your entire state tree on every action you're already slower (not just in data transfer but in code execution) than the "traditional" client-server pattern, and if you have a UX team and any timeline pressure at all, you've already written yourself into several corners for UI bells and whistles, which unfortunately affect the server side as well now, not to mention being at least a major version out of date on several NPM libraries, and just another rewrite away from clean architecture, and so on...
weego 9y ago
So you have 2 versions of the code with a shared contract between the two. Isn't that exactly what the original criticism was, other than in this world your server and client both have packaged code that is likely redundant or at least not a clean abstraction?
- Can_Not 9y ago
  We have one version of the client-side code and one version of the backend API code. The server-side code mounts the client-side code like a pure function for rendering on a user's first arrival. You can technically separate the SSR from the API if you want (might even be default in some places). "You have 2 versions of the same code" is a simple misconception from people who still think in terms of jQuery at best, at worst it's intentionally ignorant and misleading.
  - tboyd47 9y ago
    "2 versions of the same code" is not a very precise description. Either it's one chunk of code or two chunks, or one chunk that extends the other chunk in some way. What we ended up in my case was one chunk of code (server) that extends a shared chunk (server/client), with plenty of server vs. client branching inside the shared chunk, either on a boolean flag or the presence of some data structure that only exists in one environment. I have never seen the use case that many people flippantly claim is so easy, which is the "one chunk" concept, nor have I seen a chunk of server- or client-only code extend shared server-client code in a way I would describe as clean. Stuff tends to get messy when you have to deal with the space between the server and the client, like cookies, asset loading, or third-party services, or when you have to do fancy UX tricks. Then users who are used to "traditional" websites do things like refresh the page at weird times, click buttons more than once, load the app from the wrong URL, use the wrong browser, click things too fast, leave a tab open too long, and so on. And then, as others have mentioned, you have sensitive logic that needs to live only on the server for business reasons. Then the framework you're using moves too quickly or not quickly enough to support a browser feature you didn't know you needed until right now. All this stuff only comes in later, once the app meets the ground, and is rarely discussed in initial architecture meetings. The only way I could possibly see these solutions as cleaner than the old "two-chunk" way are if I were to automatically dismiss all those pragmatic concerns or consider them to be cleaner simply by virtue of the fact that they're different. It's frustrating to me because I see so much optimism on online forums about "Universal" JS as this earth-shaking sea change on the verge of happening, even though honestly it's been 10 years since NodeJS came out and first made Universal possible. It makes me feel a bit like an old fogey for throwing up my hands and saying, "Let's just let it go and stick to the original design of the web," meaning, two chunks. But that's the only way possible for me to deliver the real requirements I have on projects without driving myself crazy.