11 ms·

This type of anti-big-js comment does great on Hacker News and sounds good, but my personal experience has always been very different. Every large server-render

by cactus2093 6y ago

This type of anti-big-js comment does great on Hacker News and sounds good, but my personal experience has always been very different. Every large server-rendered app I've worked on ends up devolving to a mess of quickly thrown together js/jquery animations, validations, XHR requests, etc. that is a big pain to work on. You're often doing things like adding the same functionality twice, once on the server view and once for the manipulated resulting page in js. Every bit of interactivity/ reactivity that product wants to add to the page feels like a weird hack that doesn't quite belong there, polluting the simple, declarative model that your views started off as. None of your JS is unit tested, sometimes not even linted properly because it's mixed into the templates all over the place. The performance still isn't a given either, your rendering times can still get out of hand and you end up having to do things like caching partially rendered page fragments. The more modern style of heavier client-side js apps lets you use software development best practices to structure, reuse, and test your code in ways that are more readable and intuitive. You're still of course free to mangle it into confusing spaghetti code, but the basic structure often just feels like a better fit for the domain if you have even a moderate amount of interactivity on the page(s). As the team and codebase grows the structure starts to pay off even more in the extensibility it gives you. There can be more overhead as a trade-off, but for the majority of users these pages can still be quite usable even if they are burning more cycles on the users' CPUs, so the trade-offs are often deemed to be worth it. But over time the overhead is also lessening as e.g. the default behavior of bundlers is getting smarter and tooling is improving generally. You can even write your app as js components and then server-side render it if needed, so there's no need to go back to rails or php even if a blazing fast time to render the page is a priority.

munk-a 6y ago
I'd add that the OP was advocating for static HTML which is, in this day, unsellable to a lot of clients. I love producing static HTML server-side and in house a lot of our internal tools get written like that and operate fine. Additionally I feel like there was an implication that in such a setup the client would be doing hard processing - i.e. aggregating a raw data set on the fly - I've seen this done and it's terrible in most circumstances and it certainly isn't the norm. The server can do the heavy lifting and then hand things off to the client to do all the minor display adjustments like localization, adjusting for timezones - display stuff. A well written front-end can provide a far more responsive page by using over-fold only rendering that the server is mostly ignorant of. Both sides of the product should be independent systems setup to treat the other as foreign I/O pipe where data is just being requested and returned.
bob1029 6y ago
We side-step large parts of this argument for our more complex business UIs by leveraging server-side technologies like Blazor. We also recognize that by constraining some aspects of what we are willing to support on the UI that we get profound productivity gains. Hypothetically, if we wanted some animations in our server-side blazor apps, we could add some new methods to our JS interop shim for explicitly requesting animation of specific element ids. We could also conditionally adjust the CSS stylesheets or classes on elements for animations on round trips of client-triggered events. Putting an @if(...){} around a CSS rule is a perfectly reasonable way to get the client to do what you want when you want. In this model the client has absolutely zero business state. When you go all-in with server-side it means you always have a perfect picture of client state from the server's perspective, so you can reliably engage in this kind of logic. There are compromises that have to be made. The above is not a perfect solution for all use cases. But, it does demonstrate that with some clever engineering and new ways of thinking about problems that we can get really close to meeting in the middle of several ideal philosophies all at the same time.
userbinator 6y ago
The more modern style of heavier client-side js apps lets you use software development best practices to structure, reuse, and test your code in ways that are more readable and intuitive. I have seen phrases like that being used to (over)sell something so many times that I feel suspicious and doubtful whenever I see them --- Enterprise Java™ is sold using similar verbiage, and yet I'd never want to work with it again. Some of the worst codebase I've worked with --- ridiculously indirect and abstracted --- were created and described with such terms. I'll take spaghetti code over whatever dogmatically following "best" practices produces. The former "flows", while the latter "jumps".
andrepd 6y ago
>The more modern style of heavier client-side js apps lets you use software development best practices to structure, reuse, and test your code in ways that are more readable and intuitive. Sadly, this is probably where the core of the problem lies. "It makes code more readable and intuitive" is NOT the end goal. Making your job easier or more convenient is not the end goal. Making a good product for the user is! Software has got to be the only engineering discipline where people think it's acceptable to compromise the user experience for the sake of their convenience! I don't want to think to closely about data structures, I'll just use a list for everything: the users will eat the slowdown, because it makes my program easier to maintain. I want to program a server in a scripting language, it's easier for me: the users will eat the slowdown and the company budget will eat the inefficiency. And so on.
- aryonoco 6y ago
  Code that is easier to read is easier to maintain and easier to debug. Code that is easier to read and more intuitive will, more often than not, result in a better product and better experience for the users.
  - _jal 6y ago
    A: "Your restaurant's food tastes terrible." B: "Nutritious, healthy food will ensure the longevity of my customers, thereby maximizing lifetime customer revenue."
    - d3nj4l 6y ago
      That's an awful analogy
      - bb88 6y ago
        I just logged into nest for the first time on a new laptop. It took 15 seconds to load and get to the screen to change the temperature on the thermostat. Then I refreshed the page and it still took 10 seconds to reload. I'm sure their code is also relatively bug free.
pdr2020 6y ago
They don't understand the original tradeoffs that led to client-side only applications. Let them experience the pain of rebuilding that old wheel :)
- Raptor22 6y ago
  What were the tradeoffs? Genuinely curious.
- chrischattin 6y ago
  The original tradeoff was mega-cap FAANG companies trying to offload processing power to the client. There never was an organic open source push for SPA's or front end JS frameworks. They add a ton of tech debt and degrade the UX. Premature optimization and anti-pattern for everyone but a handful of companies, imo.
  - com2kid 6y ago
    The old world was having a complex web stack that included strange templating languages hacked onto languages that were sometimes invented before HTML was even a thing (see: Python) that spat out a mix of HTML and JavaScript. Then there was the fact that state lived on both the client and the server and could (would...) easily get out of sync leading to a crappy user experience, or even lost data. Oh and web apps of the era were slow. Like, dog slow. However bloated and crappy the reddit app is, the old Slashdot site was slower, even on broadband. > They add a ton of tech debt and degrade the UX. They remove a huge portion of the tech stack, no longer do you have a backend managing data, a back end generating HTML+JS, and a front end that is JS. Does no one remember that JQuery was used IN ADDITION TO server side rendering? And for what its worth, modern frameworks like React are not that large. A fully featured complex SPA with fancy effects, animations, and live DB connections with real time state updates can weigh in at under a megabyte. Time to first paint is another concern, but that is a much more complicated issue. If people want to complain about anything I'd say complain about ads. The SINGLE 500KB bundle being streamed down from the main page isn't taking 5 seconds to load. (And good sites will split the bundle up into parts and prioritize delivering the code that is needed for initial first use, so however long 100KB takes to transfer nowadays),
chrischattin 6y ago
> The more modern style of heavier client-side js apps lets you use software development best practices to structure, reuse, and test your code in ways that are more readable and intuitive. This reads like vague marketing speak. In reality SPA/front end JS frameworks do the exact opposite - violates all kinds of software best practices like duplicating logic server/client, creating brittle tests, conflation of concerns, etc, etc. SPA's front end JS frameworks are an anti-pattern, imo.
- robertoandred 6y ago
  On the contrary, a traditional server-side/jQuery hybrid is what results in duplicated templating and logic. A SPA at least has everything in one place.
- hombre_fatal 6y ago
  SPAs treat the browser just like any other client. If anything, it's more design-/architecture-consistent. - iOS speaks to your JSON server. - Android speaks to your JSON server. - CLI speaks to your JSON server. - Desktop GUI speaks to your JSON server. - Other machines speak to your JSON server. Meanwhile... - Browsers use browser-specific html endpoints to utilize a historical quirk where they render UI markup sent over the wire that the server has to generate, and now you're dealing with UI concerns on both the server and webclient instead of just dealing with biz-logic and data and the server. I find it very hard to see how this is somehow what avoids duplicating logic on server/client and conflating concerns.
  - chrischattin 6y ago
    I think you’re confusing the view layer with adding an entire SPA/JS framework where you duplicate the data model and offload business logic to the client vs a standard req/resp and rendering html/json or even JS from the server. It’s much much cleaner to do the latter. This is speaking from hard earned experience building web apps over the last ten years.
kohlerm 6y ago
IMHO the solution is a smart combination of server and client side rendering. Client side rendering in my experience tends to increase the number of requests, especially if you are using a microfrontend approach. More requests means more latency, unless all request are running in parallel, which is not always feasible. Note that with regards to latency the speed of the web did not change much and won't change much anytime soon (at least noton the desktop)With Vue and some other frameworks the complexity of this approach became acceptable in the meantime.
Joeri 6y ago
Every bit of interactivity/ reactivity that product wants to add to the page feels like a weird hack that doesn't quite belong there, polluting the simple, declarative model that your views started off as. This doesn’t need to be the case though. There have always been server-side frameworks which generate the client-side parts for you automatically, so you can mostly avoid writing any javascript even for the interactive parts. Check out rails/turbolinks/stimulusjs (used to build basecamp and hey.com) or the TALL stack (increasingly popular in the php community) for modern day examples.
astura 6y ago
I've worked on (non-SPA) webapps that are old enough to vote and I just have to disagree with this assessment. Beyond that, most websites are not webapps, most are serving up static or near-static content so most websites shouldn't be designed and engineered like they are complex webapps that are doing heavy data processing.
anhner 6y ago
Sounds like you mostly had experience with old style server side development (like php with no frameworks maybe?) Have you tried building an app with a more modern framework, like Phoenix or Blazor? You won't even need to write a single line of javascript. All business logic is on the server (no duplication of models) an can be easily testable. In my experience, SPAs tend to get overly complex, and they mix (and duplicate) business logic with UI logic.
michaelcampbell 6y ago
> This type of anti-big-js comment does great on Hacker News and sounds good, but my personal experience has always been very different. And yet, here we are, with a complete article devoted to the opposite effect.
sequoia 6y ago
> Every large server-rendered app I've worked on ends up devolving to a mess ... that is a big pain to work on. I can honestly say the same about every large SPA style app I've worked on and I've worked on several. Rewrites are the norm in the JavaScript arena because code devolves into a complicated mess then people look at it and say "It's just a JS app–there's no reason it should be this complicated!" Then they rewrite it with the latest framework magic, rinse, and repeat. EDIT: I have to go further and (respectfully) say this comment I'm replying to is a load of BS. It's responding to a big pile of data saying that pageload speeds are not faster today with 'well that's not my experience.' The other aspect of this comment that sets me off is what I'll call the "you don't have to use JSX to use React" type rebuttal. With this type of rebuttal, you respond to complaints about the way 99% of people use JavaScript by claiming that it's not strictly necessary to do it that way, despite the fact that "that way" is how everyone does use JS as well as the way thought-leaders & framework authors suggest you use it. It's responding to real-world conditions in workplaces with a hypothetical-world where JS is used differently than it is today. This type of argument always shifts the blame on to individual developers for "using JS wrong." When 90+% of people are "using the tool wrong" there is a problem with the tool and it's not reasonable to shift the blame to every user who's trying to follow the latest "best practices." I wish we could acknowledge the facts of the JS ecosystem (like those presented in this article) rather than deflect with "not all JavaScript apps..." when mostly what you're talking about is demos & contrived speedtests, not real-world applications. If 'ifs' and 'ands' were pots and pans, we'd have no need for a tinker.
mattgreenrocks 6y ago
This might be the root cause of the "goopy" feeling I get working on web apps. I couldn't get away from it so I just gave up on web apps entirely. So much of web tooling seems to aim to perpetuate the conceptual model of the web instead of daring to improve on it. Declarative views, for instance, are a breath of fresh air: instead of trying to put a JS/Python/Ruby coat of paint on the same ideas of what a web app should be, they aimed at trying to reduce a view to its essential complexity. In a sense, being too in love with the web keeps you at a local maximum because you think web programming should be HTML/CSS/JS only.
midrus 6y ago
It is unfair to compare the careless jQuery spaghetti that was pretty common time ago with a client side framework such as React regarding maintainability. If you put some effort (which I'm convinced is a lot less than the effort we put to build SPAs) into doing the "sprinkles" right, it can be as maintainable as the SPA or even more, with the added benefit of not sending so much crap to the end user. There are modern approaches to this (Turbolinks, stimulus, Unpoly, Intercooler, etc...), no need to do manual JQuery manipulation anymore. Pair it with Node, and you still have a pure JavaScript solution without wasting the user's CPU, memory and patience.

munk-a 6y ago

I'd add that the OP was advocating for static HTML which is, in this day, unsellable to a lot of clients. I love producing static HTML server-side and in house a lot of our internal tools get written like that and operate fine. Additionally I feel like there was an implication that in such a setup the client would be doing hard processing - i.e. aggregating a raw data set on the fly - I've seen this done and it's terrible in most circumstances and it certainly isn't the norm. The server can do the heavy lifting and then hand things off to the client to do all the minor display adjustments like localization, adjusting for timezones - display stuff. A well written front-end can provide a far more responsive page by using over-fold only rendering that the server is mostly ignorant of. Both sides of the product should be independent systems setup to treat the other as foreign I/O pipe where data is just being requested and returned.

bob1029 6y ago

We side-step large parts of this argument for our more complex business UIs by leveraging server-side technologies like Blazor. We also recognize that by constraining some aspects of what we are willing to support on the UI that we get profound productivity gains. Hypothetically, if we wanted some animations in our server-side blazor apps, we could add some new methods to our JS interop shim for explicitly requesting animation of specific element ids. We could also conditionally adjust the CSS stylesheets or classes on elements for animations on round trips of client-triggered events. Putting an @if(...){} around a CSS rule is a perfectly reasonable way to get the client to do what you want when you want. In this model the client has absolutely zero business state. When you go all-in with server-side it means you always have a perfect picture of client state from the server's perspective, so you can reliably engage in this kind of logic. There are compromises that have to be made. The above is not a perfect solution for all use cases. But, it does demonstrate that with some clever engineering and new ways of thinking about problems that we can get really close to meeting in the middle of several ideal philosophies all at the same time.

userbinator 6y ago

The more modern style of heavier client-side js apps lets you use software development best practices to structure, reuse, and test your code in ways that are more readable and intuitive. I have seen phrases like that being used to (over)sell something so many times that I feel suspicious and doubtful whenever I see them --- Enterprise Java™ is sold using similar verbiage, and yet I'd never want to work with it again. Some of the worst codebase I've worked with --- ridiculously indirect and abstracted --- were created and described with such terms. I'll take spaghetti code over whatever dogmatically following "best" practices produces. The former "flows", while the latter "jumps".

andrepd 6y ago

>The more modern style of heavier client-side js apps lets you use software development best practices to structure, reuse, and test your code in ways that are more readable and intuitive. Sadly, this is probably where the core of the problem lies. "It makes code more readable and intuitive" is NOT the end goal. Making your job easier or more convenient is not the end goal. Making a good product for the user is! Software has got to be the only engineering discipline where people think it's acceptable to compromise the user experience for the sake of their convenience! I don't want to think to closely about data structures, I'll just use a list for everything: the users will eat the slowdown, because it makes my program easier to maintain. I want to program a server in a scripting language, it's easier for me: the users will eat the slowdown and the company budget will eat the inefficiency. And so on.

aryonoco 6y ago
Code that is easier to read is easier to maintain and easier to debug. Code that is easier to read and more intuitive will, more often than not, result in a better product and better experience for the users.
- _jal 6y ago
  A: "Your restaurant's food tastes terrible." B: "Nutritious, healthy food will ensure the longevity of my customers, thereby maximizing lifetime customer revenue."
  - d3nj4l 6y ago
    That's an awful analogy
    - bb88 6y ago
      I just logged into nest for the first time on a new laptop. It took 15 seconds to load and get to the screen to change the temperature on the thermostat. Then I refreshed the page and it still took 10 seconds to reload. I'm sure their code is also relatively bug free.

pdr2020 6y ago

They don't understand the original tradeoffs that led to client-side only applications. Let them experience the pain of rebuilding that old wheel :)

Raptor22 6y ago
What were the tradeoffs? Genuinely curious.
chrischattin 6y ago
The original tradeoff was mega-cap FAANG companies trying to offload processing power to the client. There never was an organic open source push for SPA's or front end JS frameworks. They add a ton of tech debt and degrade the UX. Premature optimization and anti-pattern for everyone but a handful of companies, imo.
- com2kid 6y ago
  The old world was having a complex web stack that included strange templating languages hacked onto languages that were sometimes invented before HTML was even a thing (see: Python) that spat out a mix of HTML and JavaScript. Then there was the fact that state lived on both the client and the server and could (would...) easily get out of sync leading to a crappy user experience, or even lost data. Oh and web apps of the era were slow. Like, dog slow. However bloated and crappy the reddit app is, the old Slashdot site was slower, even on broadband. > They add a ton of tech debt and degrade the UX. They remove a huge portion of the tech stack, no longer do you have a backend managing data, a back end generating HTML+JS, and a front end that is JS. Does no one remember that JQuery was used IN ADDITION TO server side rendering? And for what its worth, modern frameworks like React are not that large. A fully featured complex SPA with fancy effects, animations, and live DB connections with real time state updates can weigh in at under a megabyte. Time to first paint is another concern, but that is a much more complicated issue. If people want to complain about anything I'd say complain about ads. The SINGLE 500KB bundle being streamed down from the main page isn't taking 5 seconds to load. (And good sites will split the bundle up into parts and prioritize delivering the code that is needed for initial first use, so however long 100KB takes to transfer nowadays),

chrischattin 6y ago

> The more modern style of heavier client-side js apps lets you use software development best practices to structure, reuse, and test your code in ways that are more readable and intuitive. This reads like vague marketing speak. In reality SPA/front end JS frameworks do the exact opposite - violates all kinds of software best practices like duplicating logic server/client, creating brittle tests, conflation of concerns, etc, etc. SPA's front end JS frameworks are an anti-pattern, imo.

robertoandred 6y ago
On the contrary, a traditional server-side/jQuery hybrid is what results in duplicated templating and logic. A SPA at least has everything in one place.
hombre_fatal 6y ago
SPAs treat the browser just like any other client. If anything, it's more design-/architecture-consistent. - iOS speaks to your JSON server. - Android speaks to your JSON server. - CLI speaks to your JSON server. - Desktop GUI speaks to your JSON server. - Other machines speak to your JSON server. Meanwhile... - Browsers use browser-specific html endpoints to utilize a historical quirk where they render UI markup sent over the wire that the server has to generate, and now you're dealing with UI concerns on both the server and webclient instead of just dealing with biz-logic and data and the server. I find it very hard to see how this is somehow what avoids duplicating logic on server/client and conflating concerns.
- chrischattin 6y ago
  I think you’re confusing the view layer with adding an entire SPA/JS framework where you duplicate the data model and offload business logic to the client vs a standard req/resp and rendering html/json or even JS from the server. It’s much much cleaner to do the latter. This is speaking from hard earned experience building web apps over the last ten years.

kohlerm 6y ago

IMHO the solution is a smart combination of server and client side rendering. Client side rendering in my experience tends to increase the number of requests, especially if you are using a microfrontend approach. More requests means more latency, unless all request are running in parallel, which is not always feasible. Note that with regards to latency the speed of the web did not change much and won't change much anytime soon (at least noton the desktop)With Vue and some other frameworks the complexity of this approach became acceptable in the meantime.

Joeri 6y ago

Every bit of interactivity/ reactivity that product wants to add to the page feels like a weird hack that doesn't quite belong there, polluting the simple, declarative model that your views started off as. This doesn’t need to be the case though. There have always been server-side frameworks which generate the client-side parts for you automatically, so you can mostly avoid writing any javascript even for the interactive parts. Check out rails/turbolinks/stimulusjs (used to build basecamp and hey.com) or the TALL stack (increasingly popular in the php community) for modern day examples.

astura 6y ago

I've worked on (non-SPA) webapps that are old enough to vote and I just have to disagree with this assessment. Beyond that, most websites are not webapps, most are serving up static or near-static content so most websites shouldn't be designed and engineered like they are complex webapps that are doing heavy data processing.

anhner 6y ago

Sounds like you mostly had experience with old style server side development (like php with no frameworks maybe?) Have you tried building an app with a more modern framework, like Phoenix or Blazor? You won't even need to write a single line of javascript. All business logic is on the server (no duplication of models) an can be easily testable. In my experience, SPAs tend to get overly complex, and they mix (and duplicate) business logic with UI logic.

michaelcampbell 6y ago

> This type of anti-big-js comment does great on Hacker News and sounds good, but my personal experience has always been very different. And yet, here we are, with a complete article devoted to the opposite effect.

sequoia 6y ago

> Every large server-rendered app I've worked on ends up devolving to a mess ... that is a big pain to work on. I can honestly say the same about every large SPA style app I've worked on and I've worked on several. Rewrites are the norm in the JavaScript arena because code devolves into a complicated mess then people look at it and say "It's just a JS app–there's no reason it should be this complicated!" Then they rewrite it with the latest framework magic, rinse, and repeat. EDIT: I have to go further and (respectfully) say this comment I'm replying to is a load of BS. It's responding to a big pile of data saying that pageload speeds are not faster today with 'well that's not my experience.' The other aspect of this comment that sets me off is what I'll call the "you don't have to use JSX to use React" type rebuttal. With this type of rebuttal, you respond to complaints about the way 99% of people use JavaScript by claiming that it's not strictly necessary to do it that way, despite the fact that "that way" is how everyone does use JS as well as the way thought-leaders & framework authors suggest you use it. It's responding to real-world conditions in workplaces with a hypothetical-world where JS is used differently than it is today. This type of argument always shifts the blame on to individual developers for "using JS wrong." When 90+% of people are "using the tool wrong" there is a problem with the tool and it's not reasonable to shift the blame to every user who's trying to follow the latest "best practices." I wish we could acknowledge the facts of the JS ecosystem (like those presented in this article) rather than deflect with "not all JavaScript apps..." when mostly what you're talking about is demos & contrived speedtests, not real-world applications. If 'ifs' and 'ands' were pots and pans, we'd have no need for a tinker.

mattgreenrocks 6y ago

This might be the root cause of the "goopy" feeling I get working on web apps. I couldn't get away from it so I just gave up on web apps entirely. So much of web tooling seems to aim to perpetuate the conceptual model of the web instead of daring to improve on it. Declarative views, for instance, are a breath of fresh air: instead of trying to put a JS/Python/Ruby coat of paint on the same ideas of what a web app should be, they aimed at trying to reduce a view to its essential complexity. In a sense, being too in love with the web keeps you at a local maximum because you think web programming should be HTML/CSS/JS only.

midrus 6y ago

It is unfair to compare the careless jQuery spaghetti that was pretty common time ago with a client side framework such as React regarding maintainability. If you put some effort (which I'm convinced is a lot less than the effort we put to build SPAs) into doing the "sprinkles" right, it can be as maintainable as the SPA or even more, with the added benefit of not sending so much crap to the end user. There are modern approaches to this (Turbolinks, stimulus, Unpoly, Intercooler, etc...), no need to do manual JQuery manipulation anymore. Pair it with Node, and you still have a pure JavaScript solution without wasting the user's CPU, memory and patience.