18 ms·

It's breathtaking to see the pendulum swing so obviously and definitively back in favor towards HTML-first and SSG/SSR-first solutions—to the degree that even t

It's breathtaking to see the pendulum swing so obviously and definitively back in favor towards HTML-first and SSG/SSR-first solutions—to the degree that even the JS-framework-hotness-du-jour braintrust is going all-in on SSG/SSR. I'm still a bit steamed from being gaslit all throughout the mid-2010s years when we were told <div id="root"></div> + SPA was The One True Way of building web applications. Even now, I run into this mindset _in the Rails community_ of all places. But thankfully we know now how this story will end, because the advantages of wildly simpler stacks which work better with modern web specs AND offer improved performance in many cases are undeniable.

x3haloed 4y ago
Ugh. Even reading this article. There’s always a The One True Way, even though there never really was. The right way always depends on the desired result.
- djbusby 4y ago
  Too pragmatic, you'll never get clicks that way
  - cyanydeez 4y ago
    >1 Simple Trick To Adjust Your Attitude to the Task
  - coldtea 4y ago
    Pragmatic? I'd call it too generic. It's about as good as "a man's got to do what a man's got to do" as life advice. Yes, there's no "one size fits all" and there are exotic needs, but there are certain good ways to build web pages that fit a vast majority of the use cases, and on the other hand, there are fads and hype.
nick_ 4y ago
> being gaslit throughout the mid-2010s This is exactly how it felt to me.
dvt 4y ago
> I'm still a bit steamed from being gaslit all throughout the mid-2010s I get downvoted into oblivion every time I criticize React on HN (I mean, for one, Vue is like 10x better imo, but that's neither here nor there). Just too much money is poured into getting people trained on React and too many folks' livelihoods is directly tied to React for a serious critique of the monstrosity it turned into. Facebook really did take over the world.
- antihero 4y ago
  Other than being owned by Facebook, I’m not sure how exactly React is a monstrosity. I think people downvote vue fans because it seems they can’t help but tirelessly bring it up any time there’s anything any React and a lot of people clearly don’t feel that vue is “better”, so it gets extremely irritating.
  - funstuff007 4y ago
    At this point, though, aren't React and Vue more similar than different?
    - steve_adams_86 4y ago
      I set out to figure out the answer to this question by writing about it and comparing various performance issues, ease of composition of components, debugging, etc. I didn’t find any particularly interesting or meaningful differences. At the template level, JSX exposes more plain old JavaScript than Vue’s templates do. I find defining and using types in JSX land more intuitive. Otherwise they’re fundamentally both excellent and very capable and neither is doing any one thing glaringly wrong. I ended up scrapping it because the deeper I went, the less interesting it got. I think it really does come down to ergonomics and preferences
      - mmcnl 4y ago
        Vue supports JSX as well, and has been doing so for years.
CharlesW 4y ago
> It's breathtaking to see the pendulum swing so obviously and definitively back in favor towards HTML-first and SSG/SSR-first solutions… Has it, for you? The pendulum has not begun to swing back from where I sit, and I don't see any indications that it ever will.
dgb23 4y ago
No pendulums are swinging here. What's happening is refinement and variation between two extremes.
- jonwinstanley 4y ago
  Yes. I remember reading that this latest approach is only really viable because of the use of HTTP2 for the requests and the adoption of that technology. The swing towards frontend made sense before this step change in latency.
  - brimble 4y ago
    AJAX was originally about speed, but as soon as it changed from fetching and injecting HTML fragments, to fetching data (usually JSON) and performing a bunch of transformations and interpretations of it before finally modifying the DOM, it's been in practice slow as hell compared with traditional server-side rendering.
    - jonwinstanley 4y ago
      Totally agree. Doing everything on the frontend is great for making the UI feel responsive, but once you start grabbing large amounts of data from an API, manipulating it on the frontend while keeping it in sync with the server, you run into some major headaches very fast.
- kevinmgranger 4y ago
  Isn't that how pendulums swing?
tomatowurst 4y ago
I'm still a bit steamed from being gaslit all throughout the mid-2010s years when we were told <div id="root"></div> + SPA was The One True Way of building web applications. omg. tell me about it. One CTO I remember flat out getting angry that his reason for using React was because Facebook was doing it. that's it We are going to see more reversion to '05 days, with financials of SaaS as interest rates rise. I remember one CFO getting mad because spending $2 to make $1 doesn't make sense as an enterprise company and that his reason was because we are in a new economy. Perhaps I'm extrapolating but it seems that the boring, predictable and old is that way because it's been through market manias, both financially and technologically during periods of novelty recycling.
- cmroanirgo 4y ago
  > One CTO I remember flat out getting angry that his reason for using React was because Facebook was doing it Lol. I find it ironic that from a developer standpoint, we're quick to jump with the latest FAANG libraries/cult thinking paradigms, but especially here on HN, we're equally quick to show the hate for those very same companies. Personally, I've found that all FAANG software is generally a good reason to not use it! (My solutions are all bricks and mortar sized, rather than oligarchal/massive advertising globalist farms)
- colonelpopcorn 4y ago
  I love the smell of ASP.NET and Telerik in the morning...
  - La_Beffa 4y ago
    that's unfair :=) asp.net core is completely different beast compared to asp.net
madeofpalk 4y ago
I think this is a bit disingenuous and misstating (or not understanding) the evolution frontend-focused web development has been through over the past 10 years. There’s no pendulum swing back to server-rendering, but rather new frameworks and techniques that involve both in unison.
- MatthiasPortzel 4y ago
  Yep. It's very convient to pretend that we jumped from Apache template-includes to React, but there was a messy time in between where client-side rendering with jQuery was extremely popular.
- woojoo666 4y ago
  Yeah I feel like every day there's an article on HN about how we're moving back to the old days without client-side frameworks. Except that's not true at all. People are still writing in React/Vue/Svelte, but now there's tooling that allows it to run on the server as well (SSR). Client-side frameworks are playing a bigger role than ever before. And there was no gas-lighting in the 2010's, SPAs are still here and many still use <div id=root>, even with SSR. We are seeing a bit of reduction in client-side bloat due to bundlers and compilers like Webpack or Svelte, but the value of client-side frameworks was never to add bloat to the client anyways. It was always about making it easier to write complex user features. So they provided things like better composability, better state management, etc. So when tools come along that provide the same benefits, while reducing client-side bloat, then of course the industry starts moving. I think there's also a slight sampling bias in HN because 90% of the posts here are articles and blog posts, both of which can be written in static html. So of course there's going to be blogs boasting about how they got away without a javascript framework. But the majority of internet users aren't browsing blogs, they're spending time on big web apps like Facebook and Youtube. And those web apps benefit greatly from these frameworks.
WesleyJohnson 4y ago
This is admittedly off topic, but how did the term "gaslight/lit" become so common in recent years? I had never heard of it until several years ago when someone close was going through therapy regarding a loved one. Now, it's like I'm shopping for a mattress and I'm being inundated with mattress ads. That's not to take way from your experience or suggest it's not the appropriate word, I'm quite sure it is. I'm just curious if I was really oblivious of concept before my own exposure to it, or if it was called something else?
- jffry 4y ago
  I don't know but Google Trends [1][2] bears out that it's very recently common. My best guess is that it has come up as part of the Amber Heard / Johnny Depp trial and that has spurred a lot of people searching for it. [1] Past 5 years, March & earlier - https://trends.google.com/trends/explore?date=2017-03-01%202022-03-01&geo=US&q=gaslit https://trends.google.com/trends/explore?date=2017-03-01%202... [2] Past 90 days including giant spike - https://trends.google.com/trends/explore?date=today%203-m&geo=US&q=gaslit https://trends.google.com/trends/explore?date=today%203-m&ge... (if you go to past year you can see the spike)
  - andai 4y ago
    "gaslighting" has a steady upward curve the last 10 years. My personal guess is that it has to do with psychology and mental health awareness going mainstream due to social media and psychology channels on YouTube. https://trends.google.com/trends/explore?date=all&geo=US&q=gaslit,gaslighting https://trends.google.com/trends/explore?date=all&geo=US&q=g...
- yourad_io 4y ago
  The term "gaslighting" derives from the 1944 film Gaslight, in which a husband uses trickery to convince his wife that she is mentally unwell so he can steal from her. Gaslighting was largely an obscure or esoteric term until the mid-2010s, when it broadly seeped into English lexicon. https://en.wikipedia.org/wiki/Gaslighting https://en.wikipedia.org/wiki/Gaslighting
- 4y ago
girvo 4y ago
Now that the Web Platform as a whole has gained so many amazing features and quality-of-developer-life improvements, I think the pendulum was always going to swing back. <div id="root" /> was the "one true way" in the early-mid 2010s for a reason. But now we're all thinking in terms of components already, so whole-pages-only is not needed -- serve up partials only, and have your thin JS layer combine them all. Use the platforms features for as much interactivity as it can get you, for UX/UI reasons, and then use small amounts of JS for those things where you can't. It's quite nice! Though I still make my bread and butter with the <div id="root" /> as it currently stands. We'll see if that changes. Hilariously, in 2016 I tried to push a "front-end web server that consumes the API and gives up HTML/HTML partials" idea that was this exact pattern, but could not get enough buy-in at the place I was at. The tools weren't quite there, so we'd have to build a lot of them ourselves. Now, the tools are built (or being built)!
grishka 4y ago
> The One True Way of building web applications To which I usually answer: I'm building a website. If I want an actual application, I don't consider hypertext with macros as a viable option.
qudat 4y ago
“wildly simpler stacks” [citation needed]. With a framework like rails you still have a front-end and you still have to solve for interactivity — unless you’re building a rudimentary CRUD app. There are modern alternatives that attempt to hide the interactivity by baking it into html attributes via a DSL, but JS is still there. I would argue that a client-side only SPA is very simple from the lens of how it is deployed: drop the files in an S3 bucket. There’s no need for a server and from that perspective, an SPA is actually a simpler stack.
- w-ll 4y ago
  Most of the web is just CRUD apps, be it php, rails, cgi calls, <your favorite language>. And no one is saying get rid of JS front end stuff, it should be used to enrich and not hinder. > drop the files in an S3 bucket If you have a completely static site you still shouldn't host of s3, that's a big no no. S3 isn't a CDN; you want a CloudFront or something else in front of that. But as soon as you need something more your gonna get lost or locked in.
  - arvinsim 4y ago
    > And no one is saying get rid of JS front end stuff, it should be used to enrich and not hinder. Having separation between the HTML on the server side and the JS on the frontend side is exactly why React become popular. Personally, I don't want to go back to the PHP+jQuery days. I want one language and one framework to handle both HTML and JS interactivity.
    - w-ll 4y ago
      > Having separation between the HTML on the server side and the JS on the frontend side is exactly why React become popular. But did they really. Cuz now i see .jsx files with sql calls, adding in static js and css, and logic with mixed html in... Its honestly blowing my mind how we got to this point. We all agreed biz logic, and view should be separated. and that html, css, js should also be in sperate files. and then .jsx or the like came along and merged them all back together in some of the ugliest code ive seen in years.
kitsunesoba 4y ago
I've always felt that it was a bit of an odd decision to put all of one's eggs in a basket that you don't own or meaningfully control (the client). The client's basket will need to hold some of your eggs sometimes, that's unavoidable in some cases, but it makes perfect sense to put as many of your eggs in the basket you do control (your back end).
- spion 4y ago
  I always felt the opposite was odd. Server side rendering felt like an odd hack due to the limitations of the platform. Imagine all you had was a PDF reader - then it would make sense to construct an application by building PDF files which contain links to other PDF files. But otherwise, why not write an actual client program that maintains its own UI state and have the server take care of what it does best - provide the data? Would you build a CLI (ncurses style or otherwise) application by fetching the TTY codes to render the current screen from a server for most user interactions?
  - kitsunesoba 4y ago
    That makes sense when the client is always a known quantity, but such is not the case with the web. While you can get an idea of what the majority of your target audience is running, there's always going to be some percentage that will be left out when writing client code for the majority browser only. There's always going to be client situations that you can't predict much less write for, and in those cases more server-heavy solutions tend to do better.
    - lolinder 4y ago
      Is a traditional desktop client really a better-known quantity than a web browser these days?
- jmbwell 4y ago
  The more your app can run client-side, the lower your bills server-side.
fallous 4y ago
The One True Way will always rise up and claim its victims, especially the inexperienced and/or naive amongst us. I sometimes think TOTW is actually an ancient one that thinks Cthulhu is an infant.
ay 4y ago
I have an app which was built 10-ish years ago using C# and which I rewrote using rust - in almost no-JS, fully server-side style. (I somewhat factored out the web framework that I ended up with - https://github.com/ayourtch/rsp10 https://github.com/ayourtch/rsp10) After reading this article I sent it to a coworker “hey if I wait for another couple years the style this app is written in will be all the rage again :-)
quickthrower2 4y ago
The SPA is definitely what you want i building an app like Google Sheets. The grey area where the pendulum might apply is in more line of businessy kind of apps: email client or online banking are examples. I think there is no pendulum though, there has just been a lot of choice in the last 10 years on all sides
- batmansmk 4y ago
  Email client: Whether or not you wanted JS, your competitor works offline, retries better when connection is not good, persists emails without having to save, live refreshes emails when received, sends notifications, allows drag and drop to organize emails, autocomplete email addresses, works in SSO, have a nice text editor with spellchecking, autocomplete, bold and italic text. You lost. Banking: your competitor handles nicely dynamic forms, with helpful field validation, asking users just the right amount of questions based on what you entered previously, without changing page, with a go back button just working great. They also live refresh transactions, provide some nice clickable spending graphs, have a nice live dynamic wire confirmation system provide in-website live chat with your advisor. Their session doesn't expire every 15min for security reasons. You lost.
  - quickthrower2 4y ago
    Actually I really love the old fashioned cubemail type interface. Faster to load, more predictable interface where opening in another tab is a thing. I am rarely in a offline situation and if I am I connect a traditional email client that apple provides on my iphone anyway. Banking - again same kind of argument. Non JS infused apps have a certain solidness about them. I think it is the predictability. An interactive site will have whatever original UX innovations that team came up with. Case in point in HN you can paste arbitrary text into a comment without it fucking up. Impossible on Reddit! If I paste there the comment box is now forever fucked until I reload. I need to do the old notepad middleman trick. Your you lost comments are odd, it is horses for courses always.
    - batmansmk 4y ago
deepstack 4y ago
>It's breathtaking to see the pendulum swing so obviously and definitively back in favor towards HTML-first and SSG/SSR-first solutions—to the degree that even the JS-framework-hotness-du-jour braintrust is going all-in on SSG/SSR. The pendulum swings large due to under-educated (and I don't only mean CS degree in school) developers, now days the industry is fill with developer wanna be jumping on the band wagon, many if not most are not really interested in software development. SPA was created to split up front-end/back-end development to cater to these new bee 'front-end' developers. That way the only thing they can screw up is the front end. The way how these Reactive app does thing, makes it easier to split that up. Front end is client/browser, backend API. It make sense from management point of view. It is stupid from a true software developer point of view. SPA also allow to control what user can and can not do. e.g: Link that doesn't allow user to open link in another page. SPA became so popular that w3 even made what so called web components to try to be like React. However, it is stupid to recreate browser rendering functionality in JS, and try to build desktop like apps in a document based system, even if V8 really made that fast by JIT compiling the JS. I do like the 2 way binding the vars. And if I'm going to us a reactive app, I would use Solid/Vue/Mithilral before I event touch React/Angular with 10 feet pole.
- robertlagrant 4y ago
  It's not just that. Making one API that can be consumed by web and mobile was also a big part of it.
bigpeopleareold 4y ago
I used to work on an single page application that was pretty complicated with heavy DOM updates. In the team, we wanted to investigate at the time if React could help us with some performance bottlenecks. However, I remember very much with that buy-in with JSX didn't appeal much to me. As we started to write more code against it, it was okay. On reflection though, I don't think React would have helped to solve the problems we thought we had. I only tried to see it as a solution to a problem, not seeking to use it to be part of a sub-industry around this library. But, even as I write this, I get a recruiter email asking for React experience. I have not followed it much for a few years, but using React now doesn't seem to fit the exact problem it tried to originally solve anymore (if that problem even matters now) but is a completely separate thing. But I really don't care anymore, because I don't work in any focused frontend web development now. I wrote something in plain JS a couple of weeks ago, up to a point where it was generally useful for myself for my work. It was wonderful - no crazy complex toolchain, no React to deal with, just html and some JS to do stuff. Doing the simplest thing in a new project (no extraneous toolchains if you can help it specifically) should be the first thing to do. This is not a fad, it's just taking stock in the time you have to make usable programs.
- robertlagrant 4y ago
  I love that some of us are all having a similar experience at the same time. I'm writing something small and I just include an htmx script tag at the top of the file and get going. It's amazing how fast something is when it's just selecting exactly what it needs from the DB and sending prerendered html to the browser.
theplumber 4y ago
SPA has been web's response to native mobile apps.
lkxijlewlf 4y ago
> I'm still a bit steamed from being gaslit all throughout the mid-2010s years when we were told <div id="root"></div> + SPA was The One True Way of building web applications. Cult-like behavior with a healthy dash of resume driven development. All it is. They tend to be the loudest people in the room and so then management says, okay, do this.
ehnto 4y ago
I think what can make some of the rhetoric around it all seem so surprising and frustrating, is because many of the proponents started their careers with the paradigm already shifted toward frontend SPAs. I started my career with the paradigm shifted toward backend templating frameworks, and when SPAs came around I remember seeing some of the old-hats with the same surprise articles like this exhibit, as we had never experienced GUI frameworks before, where they had.

x3haloed 4y ago

Ugh. Even reading this article. There’s always a The One True Way, even though there never really was. The right way always depends on the desired result.

djbusby 4y ago
Too pragmatic, you'll never get clicks that way
- cyanydeez 4y ago
  >1 Simple Trick To Adjust Your Attitude to the Task
- coldtea 4y ago
  Pragmatic? I'd call it too generic. It's about as good as "a man's got to do what a man's got to do" as life advice. Yes, there's no "one size fits all" and there are exotic needs, but there are certain good ways to build web pages that fit a vast majority of the use cases, and on the other hand, there are fads and hype.

nick_ 4y ago

> being gaslit throughout the mid-2010s This is exactly how it felt to me.

dvt 4y ago

> I'm still a bit steamed from being gaslit all throughout the mid-2010s I get downvoted into oblivion every time I criticize React on HN (I mean, for one, Vue is like 10x better imo, but that's neither here nor there). Just too much money is poured into getting people trained on React and too many folks' livelihoods is directly tied to React for a serious critique of the monstrosity it turned into. Facebook really did take over the world.

antihero 4y ago
Other than being owned by Facebook, I’m not sure how exactly React is a monstrosity. I think people downvote vue fans because it seems they can’t help but tirelessly bring it up any time there’s anything any React and a lot of people clearly don’t feel that vue is “better”, so it gets extremely irritating.
- funstuff007 4y ago
  At this point, though, aren't React and Vue more similar than different?
  - steve_adams_86 4y ago
    I set out to figure out the answer to this question by writing about it and comparing various performance issues, ease of composition of components, debugging, etc. I didn’t find any particularly interesting or meaningful differences. At the template level, JSX exposes more plain old JavaScript than Vue’s templates do. I find defining and using types in JSX land more intuitive. Otherwise they’re fundamentally both excellent and very capable and neither is doing any one thing glaringly wrong. I ended up scrapping it because the deeper I went, the less interesting it got. I think it really does come down to ergonomics and preferences
    - mmcnl 4y ago
      Vue supports JSX as well, and has been doing so for years.

CharlesW 4y ago

> It's breathtaking to see the pendulum swing so obviously and definitively back in favor towards HTML-first and SSG/SSR-first solutions… Has it, for you? The pendulum has not begun to swing back from where I sit, and I don't see any indications that it ever will.

dgb23 4y ago

No pendulums are swinging here. What's happening is refinement and variation between two extremes.

jonwinstanley 4y ago
Yes. I remember reading that this latest approach is only really viable because of the use of HTTP2 for the requests and the adoption of that technology. The swing towards frontend made sense before this step change in latency.
- brimble 4y ago
  AJAX was originally about speed, but as soon as it changed from fetching and injecting HTML fragments, to fetching data (usually JSON) and performing a bunch of transformations and interpretations of it before finally modifying the DOM, it's been in practice slow as hell compared with traditional server-side rendering.
  - jonwinstanley 4y ago
    Totally agree. Doing everything on the frontend is great for making the UI feel responsive, but once you start grabbing large amounts of data from an API, manipulating it on the frontend while keeping it in sync with the server, you run into some major headaches very fast.
kevinmgranger 4y ago
Isn't that how pendulums swing?

tomatowurst 4y ago

I'm still a bit steamed from being gaslit all throughout the mid-2010s years when we were told <div id="root"></div> + SPA was The One True Way of building web applications. omg. tell me about it. One CTO I remember flat out getting angry that his reason for using React was because Facebook was doing it. that's it We are going to see more reversion to '05 days, with financials of SaaS as interest rates rise. I remember one CFO getting mad because spending $2 to make $1 doesn't make sense as an enterprise company and that his reason was because we are in a new economy. Perhaps I'm extrapolating but it seems that the boring, predictable and old is that way because it's been through market manias, both financially and technologically during periods of novelty recycling.

cmroanirgo 4y ago
> One CTO I remember flat out getting angry that his reason for using React was because Facebook was doing it Lol. I find it ironic that from a developer standpoint, we're quick to jump with the latest FAANG libraries/cult thinking paradigms, but especially here on HN, we're equally quick to show the hate for those very same companies. Personally, I've found that all FAANG software is generally a good reason to not use it! (My solutions are all bricks and mortar sized, rather than oligarchal/massive advertising globalist farms)
colonelpopcorn 4y ago
I love the smell of ASP.NET and Telerik in the morning...
- La_Beffa 4y ago
  that's unfair :=) asp.net core is completely different beast compared to asp.net

madeofpalk 4y ago

I think this is a bit disingenuous and misstating (or not understanding) the evolution frontend-focused web development has been through over the past 10 years. There’s no pendulum swing back to server-rendering, but rather new frameworks and techniques that involve both in unison.

MatthiasPortzel 4y ago
Yep. It's very convient to pretend that we jumped from Apache template-includes to React, but there was a messy time in between where client-side rendering with jQuery was extremely popular.
woojoo666 4y ago
Yeah I feel like every day there's an article on HN about how we're moving back to the old days without client-side frameworks. Except that's not true at all. People are still writing in React/Vue/Svelte, but now there's tooling that allows it to run on the server as well (SSR). Client-side frameworks are playing a bigger role than ever before. And there was no gas-lighting in the 2010's, SPAs are still here and many still use <div id=root>, even with SSR. We are seeing a bit of reduction in client-side bloat due to bundlers and compilers like Webpack or Svelte, but the value of client-side frameworks was never to add bloat to the client anyways. It was always about making it easier to write complex user features. So they provided things like better composability, better state management, etc. So when tools come along that provide the same benefits, while reducing client-side bloat, then of course the industry starts moving. I think there's also a slight sampling bias in HN because 90% of the posts here are articles and blog posts, both of which can be written in static html. So of course there's going to be blogs boasting about how they got away without a javascript framework. But the majority of internet users aren't browsing blogs, they're spending time on big web apps like Facebook and Youtube. And those web apps benefit greatly from these frameworks.

WesleyJohnson 4y ago

This is admittedly off topic, but how did the term "gaslight/lit" become so common in recent years? I had never heard of it until several years ago when someone close was going through therapy regarding a loved one. Now, it's like I'm shopping for a mattress and I'm being inundated with mattress ads. That's not to take way from your experience or suggest it's not the appropriate word, I'm quite sure it is. I'm just curious if I was really oblivious of concept before my own exposure to it, or if it was called something else?

jffry 4y ago
I don't know but Google Trends [1][2] bears out that it's very recently common. My best guess is that it has come up as part of the Amber Heard / Johnny Depp trial and that has spurred a lot of people searching for it. [1] Past 5 years, March & earlier - https://trends.google.com/trends/explore?date=2017-03-01%202022-03-01&geo=US&q=gaslit https://trends.google.com/trends/explore?date=2017-03-01%202... [2] Past 90 days including giant spike - https://trends.google.com/trends/explore?date=today%203-m&geo=US&q=gaslit https://trends.google.com/trends/explore?date=today%203-m&ge... (if you go to past year you can see the spike)
- andai 4y ago
  "gaslighting" has a steady upward curve the last 10 years. My personal guess is that it has to do with psychology and mental health awareness going mainstream due to social media and psychology channels on YouTube. https://trends.google.com/trends/explore?date=all&geo=US&q=gaslit,gaslighting https://trends.google.com/trends/explore?date=all&geo=US&q=g...
yourad_io 4y ago
The term "gaslighting" derives from the 1944 film Gaslight, in which a husband uses trickery to convince his wife that she is mentally unwell so he can steal from her. Gaslighting was largely an obscure or esoteric term until the mid-2010s, when it broadly seeped into English lexicon. https://en.wikipedia.org/wiki/Gaslighting https://en.wikipedia.org/wiki/Gaslighting
4y ago

girvo 4y ago

Now that the Web Platform as a whole has gained so many amazing features and quality-of-developer-life improvements, I think the pendulum was always going to swing back. <div id="root" /> was the "one true way" in the early-mid 2010s for a reason. But now we're all thinking in terms of components already, so whole-pages-only is not needed -- serve up partials only, and have your thin JS layer combine them all. Use the platforms features for as much interactivity as it can get you, for UX/UI reasons, and then use small amounts of JS for those things where you can't. It's quite nice! Though I still make my bread and butter with the <div id="root" /> as it currently stands. We'll see if that changes. Hilariously, in 2016 I tried to push a "front-end web server that consumes the API and gives up HTML/HTML partials" idea that was this exact pattern, but could not get enough buy-in at the place I was at. The tools weren't quite there, so we'd have to build a lot of them ourselves. Now, the tools are built (or being built)!

grishka 4y ago

> The One True Way of building web applications To which I usually answer: I'm building a website. If I want an actual application, I don't consider hypertext with macros as a viable option.

qudat 4y ago

“wildly simpler stacks” [citation needed]. With a framework like rails you still have a front-end and you still have to solve for interactivity — unless you’re building a rudimentary CRUD app. There are modern alternatives that attempt to hide the interactivity by baking it into html attributes via a DSL, but JS is still there. I would argue that a client-side only SPA is very simple from the lens of how it is deployed: drop the files in an S3 bucket. There’s no need for a server and from that perspective, an SPA is actually a simpler stack.

w-ll 4y ago
Most of the web is just CRUD apps, be it php, rails, cgi calls, <your favorite language>. And no one is saying get rid of JS front end stuff, it should be used to enrich and not hinder. > drop the files in an S3 bucket If you have a completely static site you still shouldn't host of s3, that's a big no no. S3 isn't a CDN; you want a CloudFront or something else in front of that. But as soon as you need something more your gonna get lost or locked in.
- arvinsim 4y ago
  > And no one is saying get rid of JS front end stuff, it should be used to enrich and not hinder. Having separation between the HTML on the server side and the JS on the frontend side is exactly why React become popular. Personally, I don't want to go back to the PHP+jQuery days. I want one language and one framework to handle both HTML and JS interactivity.
  - w-ll 4y ago
    > Having separation between the HTML on the server side and the JS on the frontend side is exactly why React become popular. But did they really. Cuz now i see .jsx files with sql calls, adding in static js and css, and logic with mixed html in... Its honestly blowing my mind how we got to this point. We all agreed biz logic, and view should be separated. and that html, css, js should also be in sperate files. and then .jsx or the like came along and merged them all back together in some of the ugliest code ive seen in years.

kitsunesoba 4y ago

I've always felt that it was a bit of an odd decision to put all of one's eggs in a basket that you don't own or meaningfully control (the client). The client's basket will need to hold some of your eggs sometimes, that's unavoidable in some cases, but it makes perfect sense to put as many of your eggs in the basket you do control (your back end).

spion 4y ago
I always felt the opposite was odd. Server side rendering felt like an odd hack due to the limitations of the platform. Imagine all you had was a PDF reader - then it would make sense to construct an application by building PDF files which contain links to other PDF files. But otherwise, why not write an actual client program that maintains its own UI state and have the server take care of what it does best - provide the data? Would you build a CLI (ncurses style or otherwise) application by fetching the TTY codes to render the current screen from a server for most user interactions?
- kitsunesoba 4y ago
  That makes sense when the client is always a known quantity, but such is not the case with the web. While you can get an idea of what the majority of your target audience is running, there's always going to be some percentage that will be left out when writing client code for the majority browser only. There's always going to be client situations that you can't predict much less write for, and in those cases more server-heavy solutions tend to do better.
  - lolinder 4y ago
    Is a traditional desktop client really a better-known quantity than a web browser these days?
jmbwell 4y ago
The more your app can run client-side, the lower your bills server-side.

fallous 4y ago

The One True Way will always rise up and claim its victims, especially the inexperienced and/or naive amongst us. I sometimes think TOTW is actually an ancient one that thinks Cthulhu is an infant.

ay 4y ago

I have an app which was built 10-ish years ago using C# and which I rewrote using rust - in almost no-JS, fully server-side style. (I somewhat factored out the web framework that I ended up with - https://github.com/ayourtch/rsp10 https://github.com/ayourtch/rsp10) After reading this article I sent it to a coworker “hey if I wait for another couple years the style this app is written in will be all the rage again :-)

quickthrower2 4y ago

The SPA is definitely what you want i building an app like Google Sheets. The grey area where the pendulum might apply is in more line of businessy kind of apps: email client or online banking are examples. I think there is no pendulum though, there has just been a lot of choice in the last 10 years on all sides

batmansmk 4y ago
Email client: Whether or not you wanted JS, your competitor works offline, retries better when connection is not good, persists emails without having to save, live refreshes emails when received, sends notifications, allows drag and drop to organize emails, autocomplete email addresses, works in SSO, have a nice text editor with spellchecking, autocomplete, bold and italic text. You lost. Banking: your competitor handles nicely dynamic forms, with helpful field validation, asking users just the right amount of questions based on what you entered previously, without changing page, with a go back button just working great. They also live refresh transactions, provide some nice clickable spending graphs, have a nice live dynamic wire confirmation system provide in-website live chat with your advisor. Their session doesn't expire every 15min for security reasons. You lost.
- quickthrower2 4y ago
  Actually I really love the old fashioned cubemail type interface. Faster to load, more predictable interface where opening in another tab is a thing. I am rarely in a offline situation and if I am I connect a traditional email client that apple provides on my iphone anyway. Banking - again same kind of argument. Non JS infused apps have a certain solidness about them. I think it is the predictability. An interactive site will have whatever original UX innovations that team came up with. Case in point in HN you can paste arbitrary text into a comment without it fucking up. Impossible on Reddit! If I paste there the comment box is now forever fucked until I reload. I need to do the old notepad middleman trick. Your you lost comments are odd, it is horses for courses always.
  - batmansmk 4y ago

deepstack 4y ago

>It's breathtaking to see the pendulum swing so obviously and definitively back in favor towards HTML-first and SSG/SSR-first solutions—to the degree that even the JS-framework-hotness-du-jour braintrust is going all-in on SSG/SSR. The pendulum swings large due to under-educated (and I don't only mean CS degree in school) developers, now days the industry is fill with developer wanna be jumping on the band wagon, many if not most are not really interested in software development. SPA was created to split up front-end/back-end development to cater to these new bee 'front-end' developers. That way the only thing they can screw up is the front end. The way how these Reactive app does thing, makes it easier to split that up. Front end is client/browser, backend API. It make sense from management point of view. It is stupid from a true software developer point of view. SPA also allow to control what user can and can not do. e.g: Link that doesn't allow user to open link in another page. SPA became so popular that w3 even made what so called web components to try to be like React. However, it is stupid to recreate browser rendering functionality in JS, and try to build desktop like apps in a document based system, even if V8 really made that fast by JIT compiling the JS. I do like the 2 way binding the vars. And if I'm going to us a reactive app, I would use Solid/Vue/Mithilral before I event touch React/Angular with 10 feet pole.

robertlagrant 4y ago
It's not just that. Making one API that can be consumed by web and mobile was also a big part of it.

bigpeopleareold 4y ago

I used to work on an single page application that was pretty complicated with heavy DOM updates. In the team, we wanted to investigate at the time if React could help us with some performance bottlenecks. However, I remember very much with that buy-in with JSX didn't appeal much to me. As we started to write more code against it, it was okay. On reflection though, I don't think React would have helped to solve the problems we thought we had. I only tried to see it as a solution to a problem, not seeking to use it to be part of a sub-industry around this library. But, even as I write this, I get a recruiter email asking for React experience. I have not followed it much for a few years, but using React now doesn't seem to fit the exact problem it tried to originally solve anymore (if that problem even matters now) but is a completely separate thing. But I really don't care anymore, because I don't work in any focused frontend web development now. I wrote something in plain JS a couple of weeks ago, up to a point where it was generally useful for myself for my work. It was wonderful - no crazy complex toolchain, no React to deal with, just html and some JS to do stuff. Doing the simplest thing in a new project (no extraneous toolchains if you can help it specifically) should be the first thing to do. This is not a fad, it's just taking stock in the time you have to make usable programs.

robertlagrant 4y ago
I love that some of us are all having a similar experience at the same time. I'm writing something small and I just include an htmx script tag at the top of the file and get going. It's amazing how fast something is when it's just selecting exactly what it needs from the DB and sending prerendered html to the browser.

theplumber 4y ago

SPA has been web's response to native mobile apps.

lkxijlewlf 4y ago

> I'm still a bit steamed from being gaslit all throughout the mid-2010s years when we were told <div id="root"></div> + SPA was The One True Way of building web applications. Cult-like behavior with a healthy dash of resume driven development. All it is. They tend to be the loudest people in the room and so then management says, okay, do this.

ehnto 4y ago

I think what can make some of the rhetoric around it all seem so surprising and frustrating, is because many of the proponents started their careers with the paradigm already shifted toward frontend SPAs. I started my career with the paradigm shifted toward backend templating frameworks, and when SPAs came around I remember seeing some of the old-hats with the same surprise articles like this exhibit, as we had never experienced GUI frameworks before, where they had.