9 ms·

How did we get to the point where simple and effective server-side pages are either unknown as a way of doing things or are considered to be a technical heresy?

• LapsangGuzzler 3y ago
  Because JavaScript rules web dev and the JS community has pushed so many mainstream ideas that have turned out to be duds. It’s a major echo chamber due to its size relative to other web dev communities. I also partly blame the careerist obsession around always learning new technology, because it’s becoming obvious that a lot of the “new stuff” over the last decade created more problems than solutions. Don’t get me wrong, learning is an important part of the job, but we’ve created a culture of constantly pushing new technology to pad resumes and feed our insecurities around irrelevance instead of solving problems.
  • bheadmaster 3y ago
    It seems to me that the more people use <thing>, the less evidence of quality of <thing> is required by the people using <thing> - everyone just assumes everyone else knows what they're doing. It becomes something akin to a religion - after all, 2 billion Christians can't be wrong, can they?
    • toyg 3y ago
      Eat shit - billions of flies cannot be wrong. (cit.) More seriously: once a bit of tech becomes mainstream, it becomes politically easier to use it. Your manager has not heard of <cool tech>, but he did read about React in some business magazine. So when the choice is between React and bheadmaster's Funky Funkness Framework, he'll go with React.
      • ricardobayes 3y ago
        No one ever got fired for choosing React
        • arrowsmith 3y ago
          But some of them should have been.
    • nonethewiser 3y ago
      Can you pick a less antagonistic example?
      • bheadmaster 3y ago
        Would you prefer I used Judaism instead? Or Islam? Or do you consider my point about network effect in tech stacks being similar to religious beliefs to be antagonistic by itself?
      • brightlancer 3y ago
        The adage I learned decades ago was "a billion Chinese can't be wrong". If PP had used that, would it have been antagonistic? Racist?
        • arrowsmith 3y ago
          I thought the origin of this expression was the Elvis greatest hits album 50,000,000 Elvis fans can't be wrong: https://en.wikipedia.org/wiki/50,000,000_Elvis_Fans_Can%27t_Be_Wrong:_Elvis%27_Gold_Records,_Volume_2 https://en.wikipedia.org/wiki/50,000,000_Elvis_Fans_Can%27t_...
  • jwells89 3y ago
    Hype, which the web/JS community seems particularly vulnerable to, also plays a big part. Yes proven tech is safe and reliable, but choosing it is so much less fun than getting swept away by the tide of whatever the newest "revolution" is. Don't you want to be part of the wave?
    • LapsangGuzzler 3y ago
      Personally, not for the day job. I love experimenting with new stuff in my free time but when the pressure is on to deliver for the business, I want to go with what I know works.
• hot_gril 3y ago
  Not sure what a BFF is, but having separate frontend and backend development doesn't mean you have 20 microservices.
  • yu3zhou4 3y ago
    I think BFF might stand for Backend For Frontend in this context
    • hot_gril 3y ago
      "A BFF layer consists of multiple backends developed to address the needs of respective frontend frameworks, like desktop, browser, and native-mobile apps." Ok. Yeah that's only for huge scale things.
      • Hel5inki 3y ago
        I don’t find that to be an accurate representation of BFF. I’ve used BFF with a browser FE to simply weave several microservice endpoints into a tailor-made api for the frontend. This reduces the burden on the microservices by removing the need to make many endpoints for clients and helps reduce network calls on the FE
      • sarchertech 3y ago
        Most of the time time BFF just means that instead of having the frontend call endpoints A, B, and C. It calls a single endpoint D, which calls A, B, and C and handles aggregating and transforming the data into the specific form the frontend needs.
        • hot_gril 3y ago
          Eh, I just call that "good design" under most circumstances.
        • deleted 3y ago
          [deleted]
      • 3y ago
• TeMPOraL 3y ago
  I think it's the difference between generations of people for whom JS was an extra thing to enrich HTML documents, vs. younger generations that see HTML as merely a rendering target for JS.
  • thwarted 3y ago
    And we got here by having javascript as an embedded scripting language in things like access control management. "I'm already using javascript on the server in my polkit config!" https://www.freedesktop.org/software/polkit/docs/latest/polkit.8.html https://www.freedesktop.org/software/polkit/docs/latest/polk... https://discourse.ubuntu.com/t/use-of-javascript-rules-in-polkit/13892 https://discourse.ubuntu.com/t/use-of-javascript-rules-in-po...
• rewmie 3y ago
  > How did we get to the point where simple and effective server-side pages are either unknown as a way of doing things or are considered to be a technical heresy? We are not at that point nor we were ever at that point, or close to it. Server-side rendering has been a hot topic in JavaScript framework circles for over a decade, and React famously solved that problem so well that it is now a standard, basic technique. Also, just because you throw the same buzzword around that does not mean the problem stayed the same. Reassembling a javascript-generated DOM with a coherent state is not the same as sending a HTML document down the wire. And you know why people started assembling DOMs with JavaScript? Because sending HTML documents down the wire was too slow and did not allowed for any control over aspects that dictate perceived performance.
• oefrha 3y ago
  If you want to build a moderately complex interactive experience that doesn’t suffer from roundtrip latency on every single interaction, you need to recreate the interactive parts of DOM in JavaScript anyway (ignore wasm), else you need to do imperative updates which quickly become a nightmare. jQuery-oriented development is a classic for sure, doesn’t mean people want to go back to it.
• nonethewiser 3y ago
  > How did we get to the point where simple and effective server-side pages are either unknown as a way of doing things or are considered to be a technical heresy? Demand for interactivity. A real demand - that’s why desktop apps are now web apps. It can be over applied, sure, but there are great reasons not to serve html templates. The trend is not some massive incompetence.
  • sarchertech 3y ago
    Incompetence is the wrong word, but in an industry that grows so fast that 3 years of experience is considered senior, many people aren’t even aware that the old ways are an option. In my experience, the percentage of large react sites where someone sat down and seriously considered using old fashioned server side rendering, but decided on React because the site actually required a huge amount of interactivity is close to zero. Every React site I’ve ever been involved with in in the last say 7 years was using React because “that’s the way it’s done”, and anything else was just a post hoc justification.
    • ethbr1 3y ago
      There's also an interactivity requirement (as in, this is impossible without interactivity) and an interactivity desire (as in, UX folks want an interactive feature). So many websites now pretend they're in the former category, but would work just fine if they implemented a less-interactive form. That's how it was done in the old days! "No, you can't have that. Here's the best we can do." "Oh, that's fine." But I expect more of what's driving complicated backend/frontend split design these days is shipping the org chart (in companies large enough to have frontend and backend teams) and technology-by-consultant (where the right technology is whatever you can get a consultant in).
    • waprin 3y ago
      I built a website that was super simple using server side rendering using Django. Then I got a bunch of feature requests that made it less simple and the client-side javascript started getting crazy spaghetti code. I actually somewhat knew React before this project but besides not wanting to overcomplicate things I was hesitant because I didn't like pure client-side rendering. Then I learned NextJS makes it easy to mix/match client-side rendering and server-side rendering so I just switched to that. So now, even for a simple website, I'll probably start with React because I don't want to dig myself into a needless hole. I wrote about the experience here: https://www.billprin.com/articles/why-i-ditched-django-for-nextjs https://www.billprin.com/articles/why-i-ditched-django-for-n... And yes that post upset some people who thought I should use htmx, but React is actually pretty easy and simple. Now most of my websites are React because I know it so it's easy and simple to use what you're used to. Also, "I did it in React because that's the way it's done" isn't the worst reason because you benefit from that popularity, e.g. some library you need will have clear examples of integrating with React. I think the frontend and JS community have certainly gone off some crazy rails at points, but I also think there's a popular sentiment on HN exaggerating how off-the-rails things have gone, usually expressed by people who don't actually develop many modern-looking websites. Most of the trends have gotten popular for somewhat rational reasons, and even that stuff that has gotten a little crazy like an explosion in dependencies, is really just about tradeoffs e.g. lots of dependencies cause lots of problems but also enable code re-use so it has pros and cons.
• evantbyrne 3y ago
  The current SPA paradigm was adopted to solve a number issues that engineering teams were facing. Your sentiment is one I'm seeing a lot more as of recently, which leads me to believe we're approaching the end of the current web development paradigm. There's too much time wasted writing _glue_ when developing SPAs: database queries, back-end controllers, data serialization, network requests, front-end state, shadow dom, etc. Lots of frameworks coming out that essentially remove the need to write glue code. I expect this trend to continue until we reach the point where you are mostly just coding a few things: schema, non-generalizable business logic, and presentation.
  • martinald 3y ago
    Blazor Server, while definitely not the right thing for all applications, is the best solution I've found to this. You write all the code in one language (C#), and it streams the changes to the clientside as needed automatically. It means you can call the database in your 'frontend' HTML layouts directly and gets rid of all the glue code. You have no serialization problems because you are using the same classes everywhere, and the component structure keeps things very clean. I would say I am about 5x more productive in Blazor Server than any other frontend technology. You don't need to write APIs at all. It's just like writing static server side rendered pages but you can do dynamic stuff. It is honestly like magic. It does come with some huge downsides though, in that it needs to keep a websocket open to stream all the DOM changes from the server, and this also has memory/performance issues on the server (needs to keep state on the server all the time). Which basically rules it out of anything that needs to work over intermittent connections (mobile), and very high scale stuff (probably could be done with enough server RAM, but it's not the right tool for that). However, it's perfect for boring line of business applications that will only be accessed on solid internet connection, which is many of them. There is also Blazor Webassembly which removes the websocket part, and lets you code frontend and backend in C# still, sharing a lot of classes, though you do need some glue code to connect the database. I've heard people are having good results with gRPC for that; but haven't looked into it much (blazor server works fine for most apps IMO).
    • evantbyrne 3y ago
• ecf 3y ago
  It’s because you fossils keep thinking server-side rendering is the right call for everything and won’t consider other possibilities.
• thrashh 3y ago
  It’s because if you want to continue getting a job, you want to use what other people are using. Using most static page frameworks is like using ColdFusion for your career advancement.
  • godzillabrennus 3y ago
    We have a boot strapped and profitable app with thousands of customers written in Django that has been operating fine since 2009 with new entrants raising and spending millions to build fancy BFF/Micro Service solutions, hiring sales people, losing money for years, only to publicly state they have finally gotten to 300 customers. Job security is relative.
• kmstout 3y ago
  I'm torn. On the one hand, there are many websites I hate interacting with because they are unnecessarily structured as JS clients exchanging data with a remote server via a network link. On the other hand, it's easier for me to develop libraries and CLI clients of my own, these days getting quite far with Firefox dev tools' network view and "copy as curl," and only occasionally having to actually read the code in those JS clients. In the old days, I would have to resort to some ugly and comparatively brittle page scraping. This new world sucks for the interactive user in a browser (which is me often enough), but it's great for the guy who wants to treat a website as just a remote provider of some kind of data or service (also me often enough).