7 ms·

As a non-web dev, I have a question about this part: > There was a sad coda; as is the way of contract work, I moved on. I explained what I had built to my rep

by OskarS 3mo ago

As a non-web dev, I have a question about this part: > There was a sad coda; as is the way of contract work, I moved on. I explained what I had built to my replacement, that it always worked even without javascript. He was appalled and said, “but that’s a lot more work for us.” Why is it more work? The approach described in the article seems honestly reasonably simple: just write the standard <input> components for the form, have a submit button at the bottom. When I was making my own websites many years ago now, that's how it worked, and it wasn't that hard. Maybe it's reflecting my ignorance in this field, but doing fancy front-ends seems much harder to me.

LNSY 3mo ago
Because before there was AI Slop, there was React.
- EGreg 3mo ago
  I think Facebook with their money and Vercel with their VC funding tried hard to push the React and then the Next.js everywhere. So it arrived in time for AIs to all train on it. And now it’s the one true way :) But do we really need all that stuff? Build steps, bundling, tree shaking, all for what? And is it really simpler… hmm
  - literalAardvark 3mo ago
    There are some advantages, but the main one is probably that it stops everyone from using NoScript and breaking tracking.
brightball 3mo ago
This was the jQuery way. It was called Graceful Degradation. The entire approach went out of style with the advent of single page apps, React, Angular, VueJS, etc.
- wccrawford 3mo ago
  That's generous. I always heard people espouse that ideal, but I rarely saw them actually do it. And I never saw it at work. There were always certain UX requirements that required JS, and that meant the company wasn't interested in testing to make sure it worked without JS. None of their customers were going to use it that way. Angular, React, etc helped force it further, but they didn't cause it.
  - brightball 3mo ago
    I know I always did. CakePHP and Rails made it really easy to determine if a request came from AJAX or direct and you could slightly tweak the response to match the medium. Agree that most people didn't, but I was always an advocate.
- IshKebab 3mo ago
  jQuery and graceful degradation are different things. The vast majority of sites in the jQuery era that used jQuery did not gracefully degrade.
- 8note 3mo ago
  the shockwave and flash way was simpler. download the whole app and run it in browser. you can even run it off line!
simpaticoder 3mo ago
Simpler doesn't mean easier. Consider a chef who at their previous job started using a wood-burning stove. This is an objectively simpler tool than a gas or electric stove, yet it would be very difficult (even impossible, depending on local architecture and regulations) for a new kitchen to add one.
- LNSY 3mo ago
  I don't understand how having to pay 20 different vendors so hackers can run commands on your server barely impeded is somehow simpler.
  - simpaticoder 3mo ago
    The message you just wrote involved how many complex systems, from your keyboard switches and firmware to your BIOS and OS interrupts, to your browser, the internet and middle boxes, just to say one sentence to someone. It would be much simpler (and more secure!) if you just told me with your mouth, but you didn't do that.
    - LNSY 3mo ago
      Of course, and if you use all these services you can be a pedantic ass who never has to actually ship a product.
- squidbeak 3mo ago
  I'm interested to hear what architecture and regulations prevent the use of something that is foundational to web develpment and backwards compatible by design? Which also, by the way, comes with the advantage of not incinerating other parts of the restaurant (accessibility, user experience...), forcing expensive countermeasures or total rebuilds of the things destroyed every time you turn it on.
- kstrauser 3mo ago
  90% of the SPAs I use could be Django/Rails/Flask apps with no noticeable difference, other than that they'd be many times more responsive on slower devices. "Old" SSR apps are mature, not obsolete. It's ridiculous when they're not considered even when they'd be the right tool for the job. I wouldn't try to clone Google Docs in Django, but something like Linear could 100% be modeled as a CRUD app with new page loads on click without a substantial loss of functionality from the user's POV. Not to mention built-in, automatic support for pervasive "deep linking", aka "linking", because you access a URL's contents by GETting and rendering that URL is just how it works.
theflyinghorse 3mo ago
It probably has to do with what technology people are used to. There has been a couple of generations of web developers who have only known javascript and its ecosystem for building webapps, and so anything other than pure javascript solution looks foreign.
- deleted 3mo ago
  [deleted]
atoav 3mo ago
By this point people don't appear to have any real clue how to write HTML anymore. Writing semantic HTML isn't significantly harder than say writing Markdown. You copy some HTMl skeleton and you literally just stack your elements into the body. I managed to do that as a 13 year old on MySpace without any deep instruction. Sure you have to close elements as well so the syntax is slightly harder than markdown, but that allows you to differenciate between for example <article>, <section> and <aside>. I am convinced the one single thing that made HTML unusable over the time was that people wanted or needed a way to re-use parts of the page across multiple pages, like headers, navigational elements and footers. This meant people used frames, PHP, templating engines or any other new technology mainly for the purpose of creating shared elements, simply because HTML failed (and to this day: fails) to offer a way to include one HTML file in another without having it suck (like frames definitely did, since the browser treated each subpart of the page like its own entity including caching).
- autoexec 3mo ago
  Large websites resorted to PHP and server side includes to get headers and footers. Smaller websites resorted to frames and copy/paste. It wasn't perfect, but it also wasn't horrible or unusable either.
  - youngtaff 3mo ago
    Ikea relies heavily on Edge Side Includes, assembling static pages from parts at the CDN level and then having small islands of JS interactivity
- jmye 3mo ago
  I think it was... SHTML? that allowed for server includes. My recollection from... 25ish years ago was that it was generally quite well supported and worked quite well (and was dead simple to implement). Not sure why, if that was the issue, the fix didn't quite catch on (but it's totally possible I'm mis-remembering the state of browser support).
  - EvanAnderson 3mo ago
rhelmer 3mo ago
I suspect they are both more familiar with client-side rendering, and also thinking of things being able to share components, reuse existing libraries, and so on. So re-implementing everything with vanilla HTML and forms feels like reinventing the wheel to a team used to an SPA component library, it's not that it's intrinsically harder, it's that they don't have the existing building blocks they'd normally reach for. Modern frameworks such as Astro allow for a similar development experience (and can optionally use JS, React and other client-side libraries) while still being able to generate a static site if desired. I think server-side rendering and static site generation are less familiar to many web devs who came up in the React/Vue/Svelte era. The patterns and mental model are just different. In an ideal world we combine both: fast static HTML that works everywhere, with progressive enhancement for interactivity. Astro does this well; Next.js supports it too, though the SSR parts have a learning curve.
chao- 3mo ago
Starting a few years ago, I realized some junior and medior engineers never once considered the possibility of building a website (app, experience, etc.) in anything other than a heavy SPA framework. But they're not stupid people! If you directly asked "Can you build a website without React?" they know the answer is obviously "Yes." However, if you asked them to build a new website, they would unthinkingly start a new React project, mostly out of familiarity and a desire to get the job done. A few of them would outright not know how to do anything else. No knowledge of how to stand up a boring HTTP server to send pure HTML. No experience building a form that validates or submits without JavaScript. These are not the people who post here on HN. They are not engaged in online discussions of new tools and skills (or old tools and skills!). These are people who learned just enough from a bootcamp, or their uni's single "web apps" course, to get a job. Since then, they have just-in-time learned whatever their employer required, or whatever particular tools someone else on their team chose for a project. As an old, it took me a while to recognize/realize it, but I understand them now. Depending on their career path, someone will encounter the simplest aspects of HTML, CSS and vanilla JavaScript after they learn the complex, framework-specific aspects of each. It feels (to them) like more esoteric, advanced, or tertiary knowledge. Tying it back to to the quote "that’s a lot more work for us", that's not necessarily an intentionally false claim. It probably does feel like a lot more work to perform a task using unfamiliar tools, even if they are less-complex tools.
- concinds 3mo ago
  You are far too empathetic to them. They should not hold the jobs they have. These are the people writing React monstrosities for government benefit websites, and testing them on fast iPhones and fast 4G, without realizing that every page load for actual users will take 30 seconds on their old $200 Android on 3G, and users won’t complete the form. It’s a culture of not giving a shit, that’s the deeper issue.
  - preg_match 3mo ago
    Most companies actively punish you for giving a shit. The more shit you give, the worse things get for you. Not giving a shit is a form of self-preservation.
seangrogg 3mo ago
As a web dev a lot of this is simply ongoing maintenance of a largely unknown quantity. Most web devs know React and use it extensively; Astro is something they'll have to learn on the job or hire for specifically. It's akin to writing a backend in Haskell. Chances are you could write something performant that leverages FP in a way that serves as a magic bullet for your domain. But now everyone after you needs to learn Haskell and how to model all future problems in a way that conforms with it - or rewrite things again.
- oldandboring 3mo ago
  > Astro is something they'll have to learn on the job or hire for specifically. Before LLMs I would have agreed.
  - hungryhobbit 3mo ago
    LLM + framework you don't understand goes in ... unmaintainable garbage comes out.
    - CSSer 3mo ago
      Before LLMs, learning on the job looked like reading documentation. Now it’s a guided tour with verification. When I produce things in this way, I’m not just blindly accepting it. The goal is that by the end of it I have learned more about the codebase and architecture, not less. I feel that’s important.
      - skellera 3mo ago
        Many people don't understand this, even big tech engineers. They see LLMs as a bottleneck. It's more that they don't understand how to use it to multiply their skills, just basics and code gen.
        hungryhobbit 3mo ago
        I use multiple Claudes at a time, daily. It's precisely because of that experience that I wrote: LLM + framework you don't understand goes in ... unmaintainable garbage comes out. Claude follows code patterns and structure. If you setup that structure and those patterns properly, it will produce great code. If not, it will follow ... whatever it feels like, with each commit. If you just have it built something with a framework you don't understand, it will do so just fine! But over time every "vibe coded" change you make will drift it further and further, until you are left with a mess of vibe-coded spaghetti.
deleted 3mo ago
[deleted]
deleted 3mo ago
[deleted]
egeozcan 3mo ago
I think the problem is hearing just one side. Someone is saying that they delivered a very reasonable solution that's simpler than most would come up. Person taking over was not happy. Do we know if the code being handed over was high quality? Were they reacting to the fact that it was "not React"? Maybe they have a template they enforce in the company about how apps are built? We don't know.
- electromech 3mo ago
  The author open sourced the validation library: https://gitlab.com/alistairldavidson/validation-enhancer https://gitlab.com/alistairldavidson/validation-enhancer
c-hendricks 3mo ago
As an application becomes more stateful it gets harder to keep that state aligned across the frontend and backend, especially if they're in different languages.
WorldMaker 3mo ago
A lot of developers have made or just perceive very strong silos between frontend and backend today. Any coordination that needs to happen between frontend and backend is potentially a communication challenge. It seems like a lot more work because you have to keep the backend and frontend in closer sync. The backend has to be aware of and able to store every sub-form in the full process (which sounds like a "wizard form" with a multiple sub-forms to get through the full "form" process), not just accept a "finished" or "complete" submission. If a sub-form needs a change the backend, the backend's storage, and the frontend all need to change. The backend and frontend have to agree on validation logic for each small piece of the form. The backend and the frontend need to both validate every small piece of the form, and maybe can't share that validation logic (depending on what language the backend is written in), especially if one of the goals is to do as much of the frontend validation as possible with Browser native validation tools (`<input required` and `<input type="email"` and so forth) so that you get the most benefits of progressive enhancement. The original ways of making websites were "full stack" and from a full stack perspective it shouldn't seem that hard to have a coordinated frontend and backend, especially when a progressive enhancement approach likely means a smaller more agile frontend, but current siloed world where frontend and backend are different teams with different goals and alignment makes that seem like way too much work.
- hacker_homie 3mo ago
  I have had issues where the Frontend team is unable to explain how to communicate with their SPA, they say "just use this package/just run node" and are unable to explain the workflow in primitives. Then they just validate on the front end, and we validate on the backend.
  - re-thc 3mo ago
    > they say "just use this package/just run node" and are unable to explain the workflow in primitives Now it's worse. It's "just run <claude or codex>"
apothegm 3mo ago
They don’t know how to compose and style elements without someone providing them with a prebuilt library of $framework components.
bachmeier 3mo ago
> Why is it more work? As someone that reads a lot of code written by others, I'm confident that "learning a new way to do something" is perceived by many as the hardest thing in the world.
nosioptar 3mo ago
I used to do web dev. (Got out of it due to js frameworks and their bloat.) I'd pee myself in happiness to take over a project like this.
duderific 3mo ago
I was confused by that too, but then I thought maybe the new replacement was commenting that using javascript in the app would provide more work for contractors, which he perceives as a good thing. So not using javascript provides less work. I could be wrong though.
iamjs 3mo ago
Two years ago, I started a new company, and decided at the outset to avoid using any heavy JavaScript SPA framework. We stuck to simple server-rendered html and only use progressive-enhancement style JavaScript. Our app was fast, and simple, but it also came at a cost: we were limited in our ability to take rich UI elements off the shelf with an npm package. We had to do a lot more work to provide a rich user experience. Everything took longer, and the user experience was worse as a result. We cared, but sometimes you don't have time to carry through. The company failed, and I don't think react would have saved it. But I can tell you first hand that righteous adherence to "simplicity" didn't help either. It's always a trade-off.
- aturek 3mo ago
  I also prefer simple web tech, but I'm really glad you brought these points up! Ecosystems matter more than a lot of purist devs think.
- creesch 3mo ago
  I feel like there is some context missing in your story here. There is a lot of middleground between heavy SPA frameworks and creating everything from scratch. More importantly, I am left wondering what sort of functionality was your team trying to build that requires that much interactivity? At least that is what I assume with "rich user experience"?
  - yurishimo 3mo ago
    If I had to guess, they were probably wanting to implement something like animations into the UI. Animating a list of items onload in a staggered format is still basically impossible unless 100% of your users are using Chrome. With a JS animation+component library, this type of animation is pretty much plug-n-play. When the startup is trying to attract customers and also impress investors, sometimes there is a lot of effort spent on the investors just so they keep putting money into the machine. "See! We have an ultra modern/sleek site so it must be some other variable that is causing customers to churn..."
gosub100 3mo ago
I'm risking being wrong here, but I think the difficulty is getting conforming behavior across all device and browser combos.
- sublinear 3mo ago
  This is the only correct answer in this entire thread! Congrats!
dapperdrake 3mo ago
Computers are very good at repeating a known "recipe". They can add numbers billions of time per second. Yes, billions with a bee. The hard part is coming up with a recipe that solves your problem and that the machine can run without breaking things when it runs around with a few billion steps per second. You have to think ahead for it and handle edge cases in the recipe. That is the really hard part.
victorbjorklund 3mo ago
It is harder to do more with less. There is a reason React and other is used so much. Makes it easier to make interactive websites. It’s like asking why backend engineers think it’s harder to code an api using C instead of using Django.
- acdha 3mo ago
  I used to think that was true but I now think it’s only true for very interaction-heavy apps: if you have hundreds of interactions on a page over many minutes, using an SPA is amortized across a lot of time, but if it’s something you could do with e.g. a simple Django app you’ll not only be done faster but will spend an order of magnitude less time on maintenance and accessibility work.
  - zelphirkalt 3mo ago
    That's usually not even in the books of a typical SPA: It doesn't have fallbacks at all, and just shows a blank white page. Accessibility is always taking a rear seat with such SPAs.
    - acdha 3mo ago
      It can be really difficult for people with screen readers: focus jumps, inconsistent update flow, too many or not enough announcements, etc. People just want to live their lives, not have to threaten 508 to be able to pay their cable bill as easily as it was 20 years ago.
  - victorbjorklund 3mo ago
    Alright but Django isn’t a pure HTML file only solution. If you have a site with no interactivity it seems like Django is the wrong choice if everything is static.
    - acdha 3mo ago
      Who said it was? My point was simply that if you’re doing something like getting data in and out of a SQL database using web forms, you can avoid a ton of overhead and deliver a better user experience without using an SPA, and of course there’s a lot to be said for not needing to install security patches weekly due to having fewer, simpler moving parts.
pbalau 3mo ago
The short and sad answer is that most people that work in web development do not understand how the web works or how web apps work.
austin-cheney 3mo ago
[dead]
Traubenfuchs 3mo ago
Modern web/frontend devs do NOT understand whole page navigating form POST calls from a pre JS era.
meander_water 3mo ago
As someone who has built both react based frontends and html based ones (with htmx), there is a law of diminishing returns at play. To start off, writing a basic crud website with forms is much easier with htmx. But when you start building more complex components, and integrate with other systems (OAuth for e.g.) there are tons of libraries and SDKs for the react ecosystem, but not many for pure html components. At this point, it's much easier to use off the shelf components than it is to manually write html to handle all the bizarre UI edge cases.
- meander_water 3mo ago
  Really curious to understand why I'm being downvoted. I don't think it's a particularly spicy take - Just choose the right tool for the job.
  - yurishimo 3mo ago
    I think a lot of people here don't seem to understand or appreciate the diversity of systems that "web developers" have to work in. Some people might say, "Why do you need all that oAuth complexity? Rip it out and use a cookie like God intended." We, the devs/ICs, don't often get to make those decisions. We're placed into teams working on specific features/apps/tools and we often have to integrate with a myriad of business systems by default. Yea, I would love to work on a simpler system, but I don't get to make that decision. Especially not when my company has been acquired by unbounded VC cash three times in the past 5 years and now I'm forced to fold in my lovingly crafted baby into the behemoth.
em-bee 3mo ago
my most recent website is fully static html and css. it contains several pages and a menu that is duplicated in all pages. that menu is maintained manually, and every time a page is added, all copies of the menu have to be updated. at some point that will get tedious. then i have a few options: i generate the menu using a backend framework. the downside: the website is no longer fully static. i now depend on a backend framework for hosting. static hosting is out. i also have to edit the content through the backend, and i have to continuously maintain the backend for the lifetime of the site. i generate the menu using a static site builder. the downside: i can no longer edit the content directly in html. i have to keep a source version for the static site generator, and more critically, i have to keep a copy of the site generator in my repo because i want to be able to make changes to this site 10 years from now and not find that the version of the site generator i was using is no longer available for download and my source is not compatible with the new version of the site generator. i generate the menu using xslt. works, but xslt is no better than javascript security wise. it's possibly even worse. and xslt support may be removed from browsers in the future. the final option is javascript. using some framework that doesn't need build tools, or something homegrown. i am afraid javascript is the only option that is futureproof while letting me avoid manual work to maintain the menu.
- creesch 3mo ago
  While purists will disagree, a little bit of javascript is fine. Having said that, you are talking about a personal website. Most companies will have a backend of some sort anyway. Also, here is a little secret. If you want something that is future proof, try something that has been around for decades and still runs large parts of the internet. People will scoff at this, but PHP is actually really neat for personal websites and has been for decades. A while ago I also found myself looking at static site generators, workflows from github to my host, etc. Eventually I realized I don't update things nearly enough, don't blog, etc. For similar reasons as you I didn't want to go completely static as that is just too much hassle when doing multiple pages. So I decided to utilize that good old lamp stack to basically do something like this. <?php $pages = json_decode(file_get_contents('pages.json'), true); $page = $_GET['page'] ?? 'home'; if (!isset($pages[$page])) { $page = 'home'; } $pageData = $pages[$page]; $contentFile = basename($pageData['file']); $contentFilePath = "content/{$contentFile}"; ?> <html> <head> <title><?= htmlspecialchars($pageData['title']) ?></title> </head> <body> <main> <?php include $contentFilePath; ?> </main> </body> </html> Slightly more, but the base principle is the same. Just 10 lines of php code, and now I can just add pages by uploading their contents and adding them to the json file for whitelisting. For your use case it would be trivial to add a menu based on the json file and I'd be confident that it will still work in 10 years with minimal adjustments. As a bonus I also rediscovered PHP in itself works really well as a templating language (as you can see) so no need for extra stuff like handlebars. As an extra extra bonus, I can just go to any shared webhosting party and get it running with no issue at all. I am not saying you'd need to go down this road. But I just want to illustrate how stupidly simple a website can be with "old" basic technologies even if you want some form of backend.
nailer 3mo ago
> Why is it more work? People expect the entire screen not to redraw whenever they interact with an app and expect behaviour asides from the HTML defaults.

by OskarS 3mo ago

LNSY 3mo ago

Because before there was AI Slop, there was React.

EGreg 3mo ago
I think Facebook with their money and Vercel with their VC funding tried hard to push the React and then the Next.js everywhere. So it arrived in time for AIs to all train on it. And now it’s the one true way :) But do we really need all that stuff? Build steps, bundling, tree shaking, all for what? And is it really simpler… hmm
- literalAardvark 3mo ago
  There are some advantages, but the main one is probably that it stops everyone from using NoScript and breaking tracking.

brightball 3mo ago

This was the jQuery way. It was called Graceful Degradation. The entire approach went out of style with the advent of single page apps, React, Angular, VueJS, etc.

wccrawford 3mo ago
That's generous. I always heard people espouse that ideal, but I rarely saw them actually do it. And I never saw it at work. There were always certain UX requirements that required JS, and that meant the company wasn't interested in testing to make sure it worked without JS. None of their customers were going to use it that way. Angular, React, etc helped force it further, but they didn't cause it.
- brightball 3mo ago
  I know I always did. CakePHP and Rails made it really easy to determine if a request came from AJAX or direct and you could slightly tweak the response to match the medium. Agree that most people didn't, but I was always an advocate.
IshKebab 3mo ago
jQuery and graceful degradation are different things. The vast majority of sites in the jQuery era that used jQuery did not gracefully degrade.
8note 3mo ago
the shockwave and flash way was simpler. download the whole app and run it in browser. you can even run it off line!

simpaticoder 3mo ago

Simpler doesn't mean easier. Consider a chef who at their previous job started using a wood-burning stove. This is an objectively simpler tool than a gas or electric stove, yet it would be very difficult (even impossible, depending on local architecture and regulations) for a new kitchen to add one.

LNSY 3mo ago
I don't understand how having to pay 20 different vendors so hackers can run commands on your server barely impeded is somehow simpler.
- simpaticoder 3mo ago
  The message you just wrote involved how many complex systems, from your keyboard switches and firmware to your BIOS and OS interrupts, to your browser, the internet and middle boxes, just to say one sentence to someone. It would be much simpler (and more secure!) if you just told me with your mouth, but you didn't do that.
  - LNSY 3mo ago
    Of course, and if you use all these services you can be a pedantic ass who never has to actually ship a product.
squidbeak 3mo ago
I'm interested to hear what architecture and regulations prevent the use of something that is foundational to web develpment and backwards compatible by design? Which also, by the way, comes with the advantage of not incinerating other parts of the restaurant (accessibility, user experience...), forcing expensive countermeasures or total rebuilds of the things destroyed every time you turn it on.
kstrauser 3mo ago
90% of the SPAs I use could be Django/Rails/Flask apps with no noticeable difference, other than that they'd be many times more responsive on slower devices. "Old" SSR apps are mature, not obsolete. It's ridiculous when they're not considered even when they'd be the right tool for the job. I wouldn't try to clone Google Docs in Django, but something like Linear could 100% be modeled as a CRUD app with new page loads on click without a substantial loss of functionality from the user's POV. Not to mention built-in, automatic support for pervasive "deep linking", aka "linking", because you access a URL's contents by GETting and rendering that URL is just how it works.

theflyinghorse 3mo ago

It probably has to do with what technology people are used to. There has been a couple of generations of web developers who have only known javascript and its ecosystem for building webapps, and so anything other than pure javascript solution looks foreign.

deleted 3mo ago
[deleted]

atoav 3mo ago

By this point people don't appear to have any real clue how to write HTML anymore. Writing semantic HTML isn't significantly harder than say writing Markdown. You copy some HTMl skeleton and you literally just stack your elements into the body. I managed to do that as a 13 year old on MySpace without any deep instruction. Sure you have to close elements as well so the syntax is slightly harder than markdown, but that allows you to differenciate between for example <article>, <section> and <aside>. I am convinced the one single thing that made HTML unusable over the time was that people wanted or needed a way to re-use parts of the page across multiple pages, like headers, navigational elements and footers. This meant people used frames, PHP, templating engines or any other new technology mainly for the purpose of creating shared elements, simply because HTML failed (and to this day: fails) to offer a way to include one HTML file in another without having it suck (like frames definitely did, since the browser treated each subpart of the page like its own entity including caching).

autoexec 3mo ago
Large websites resorted to PHP and server side includes to get headers and footers. Smaller websites resorted to frames and copy/paste. It wasn't perfect, but it also wasn't horrible or unusable either.
- youngtaff 3mo ago
  Ikea relies heavily on Edge Side Includes, assembling static pages from parts at the CDN level and then having small islands of JS interactivity
jmye 3mo ago
I think it was... SHTML? that allowed for server includes. My recollection from... 25ish years ago was that it was generally quite well supported and worked quite well (and was dead simple to implement). Not sure why, if that was the issue, the fix didn't quite catch on (but it's totally possible I'm mis-remembering the state of browser support).
- EvanAnderson 3mo ago

rhelmer 3mo ago

I suspect they are both more familiar with client-side rendering, and also thinking of things being able to share components, reuse existing libraries, and so on. So re-implementing everything with vanilla HTML and forms feels like reinventing the wheel to a team used to an SPA component library, it's not that it's intrinsically harder, it's that they don't have the existing building blocks they'd normally reach for. Modern frameworks such as Astro allow for a similar development experience (and can optionally use JS, React and other client-side libraries) while still being able to generate a static site if desired. I think server-side rendering and static site generation are less familiar to many web devs who came up in the React/Vue/Svelte era. The patterns and mental model are just different. In an ideal world we combine both: fast static HTML that works everywhere, with progressive enhancement for interactivity. Astro does this well; Next.js supports it too, though the SSR parts have a learning curve.

chao- 3mo ago

Starting a few years ago, I realized some junior and medior engineers never once considered the possibility of building a website (app, experience, etc.) in anything other than a heavy SPA framework. But they're not stupid people! If you directly asked "Can you build a website without React?" they know the answer is obviously "Yes." However, if you asked them to build a new website, they would unthinkingly start a new React project, mostly out of familiarity and a desire to get the job done. A few of them would outright not know how to do anything else. No knowledge of how to stand up a boring HTTP server to send pure HTML. No experience building a form that validates or submits without JavaScript. These are not the people who post here on HN. They are not engaged in online discussions of new tools and skills (or old tools and skills!). These are people who learned just enough from a bootcamp, or their uni's single "web apps" course, to get a job. Since then, they have just-in-time learned whatever their employer required, or whatever particular tools someone else on their team chose for a project. As an old, it took me a while to recognize/realize it, but I understand them now. Depending on their career path, someone will encounter the simplest aspects of HTML, CSS and vanilla JavaScript after they learn the complex, framework-specific aspects of each. It feels (to them) like more esoteric, advanced, or tertiary knowledge. Tying it back to to the quote "that’s a lot more work for us", that's not necessarily an intentionally false claim. It probably does feel like a lot more work to perform a task using unfamiliar tools, even if they are less-complex tools.

concinds 3mo ago
You are far too empathetic to them. They should not hold the jobs they have. These are the people writing React monstrosities for government benefit websites, and testing them on fast iPhones and fast 4G, without realizing that every page load for actual users will take 30 seconds on their old $200 Android on 3G, and users won’t complete the form. It’s a culture of not giving a shit, that’s the deeper issue.
- preg_match 3mo ago
  Most companies actively punish you for giving a shit. The more shit you give, the worse things get for you. Not giving a shit is a form of self-preservation.

seangrogg 3mo ago

As a web dev a lot of this is simply ongoing maintenance of a largely unknown quantity. Most web devs know React and use it extensively; Astro is something they'll have to learn on the job or hire for specifically. It's akin to writing a backend in Haskell. Chances are you could write something performant that leverages FP in a way that serves as a magic bullet for your domain. But now everyone after you needs to learn Haskell and how to model all future problems in a way that conforms with it - or rewrite things again.

oldandboring 3mo ago
> Astro is something they'll have to learn on the job or hire for specifically. Before LLMs I would have agreed.
- hungryhobbit 3mo ago
  LLM + framework you don't understand goes in ... unmaintainable garbage comes out.
  - CSSer 3mo ago
    Before LLMs, learning on the job looked like reading documentation. Now it’s a guided tour with verification. When I produce things in this way, I’m not just blindly accepting it. The goal is that by the end of it I have learned more about the codebase and architecture, not less. I feel that’s important.
    - skellera 3mo ago
      Many people don't understand this, even big tech engineers. They see LLMs as a bottleneck. It's more that they don't understand how to use it to multiply their skills, just basics and code gen.
      - hungryhobbit 3mo ago
        I use multiple Claudes at a time, daily. It's precisely because of that experience that I wrote: LLM + framework you don't understand goes in ... unmaintainable garbage comes out. Claude follows code patterns and structure. If you setup that structure and those patterns properly, it will produce great code. If not, it will follow ... whatever it feels like, with each commit. If you just have it built something with a framework you don't understand, it will do so just fine! But over time every "vibe coded" change you make will drift it further and further, until you are left with a mess of vibe-coded spaghetti.

deleted 3mo ago

[deleted]

deleted 3mo ago

[deleted]

egeozcan 3mo ago

I think the problem is hearing just one side. Someone is saying that they delivered a very reasonable solution that's simpler than most would come up. Person taking over was not happy. Do we know if the code being handed over was high quality? Were they reacting to the fact that it was "not React"? Maybe they have a template they enforce in the company about how apps are built? We don't know.

electromech 3mo ago
The author open sourced the validation library: https://gitlab.com/alistairldavidson/validation-enhancer https://gitlab.com/alistairldavidson/validation-enhancer

c-hendricks 3mo ago

As an application becomes more stateful it gets harder to keep that state aligned across the frontend and backend, especially if they're in different languages.

WorldMaker 3mo ago

A lot of developers have made or just perceive very strong silos between frontend and backend today. Any coordination that needs to happen between frontend and backend is potentially a communication challenge. It seems like a lot more work because you have to keep the backend and frontend in closer sync. The backend has to be aware of and able to store every sub-form in the full process (which sounds like a "wizard form" with a multiple sub-forms to get through the full "form" process), not just accept a "finished" or "complete" submission. If a sub-form needs a change the backend, the backend's storage, and the frontend all need to change. The backend and frontend have to agree on validation logic for each small piece of the form. The backend and the frontend need to both validate every small piece of the form, and maybe can't share that validation logic (depending on what language the backend is written in), especially if one of the goals is to do as much of the frontend validation as possible with Browser native validation tools (`<input required` and `<input type="email"` and so forth) so that you get the most benefits of progressive enhancement. The original ways of making websites were "full stack" and from a full stack perspective it shouldn't seem that hard to have a coordinated frontend and backend, especially when a progressive enhancement approach likely means a smaller more agile frontend, but current siloed world where frontend and backend are different teams with different goals and alignment makes that seem like way too much work.

hacker_homie 3mo ago
I have had issues where the Frontend team is unable to explain how to communicate with their SPA, they say "just use this package/just run node" and are unable to explain the workflow in primitives. Then they just validate on the front end, and we validate on the backend.
- re-thc 3mo ago
  > they say "just use this package/just run node" and are unable to explain the workflow in primitives Now it's worse. It's "just run <claude or codex>"

apothegm 3mo ago

They don’t know how to compose and style elements without someone providing them with a prebuilt library of $framework components.

bachmeier 3mo ago

> Why is it more work? As someone that reads a lot of code written by others, I'm confident that "learning a new way to do something" is perceived by many as the hardest thing in the world.

nosioptar 3mo ago

I used to do web dev. (Got out of it due to js frameworks and their bloat.) I'd pee myself in happiness to take over a project like this.

duderific 3mo ago

I was confused by that too, but then I thought maybe the new replacement was commenting that using javascript in the app would provide more work for contractors, which he perceives as a good thing. So not using javascript provides less work. I could be wrong though.

iamjs 3mo ago

Two years ago, I started a new company, and decided at the outset to avoid using any heavy JavaScript SPA framework. We stuck to simple server-rendered html and only use progressive-enhancement style JavaScript. Our app was fast, and simple, but it also came at a cost: we were limited in our ability to take rich UI elements off the shelf with an npm package. We had to do a lot more work to provide a rich user experience. Everything took longer, and the user experience was worse as a result. We cared, but sometimes you don't have time to carry through. The company failed, and I don't think react would have saved it. But I can tell you first hand that righteous adherence to "simplicity" didn't help either. It's always a trade-off.

aturek 3mo ago
I also prefer simple web tech, but I'm really glad you brought these points up! Ecosystems matter more than a lot of purist devs think.
creesch 3mo ago
I feel like there is some context missing in your story here. There is a lot of middleground between heavy SPA frameworks and creating everything from scratch. More importantly, I am left wondering what sort of functionality was your team trying to build that requires that much interactivity? At least that is what I assume with "rich user experience"?
- yurishimo 3mo ago
  If I had to guess, they were probably wanting to implement something like animations into the UI. Animating a list of items onload in a staggered format is still basically impossible unless 100% of your users are using Chrome. With a JS animation+component library, this type of animation is pretty much plug-n-play. When the startup is trying to attract customers and also impress investors, sometimes there is a lot of effort spent on the investors just so they keep putting money into the machine. "See! We have an ultra modern/sleek site so it must be some other variable that is causing customers to churn..."

gosub100 3mo ago

I'm risking being wrong here, but I think the difficulty is getting conforming behavior across all device and browser combos.

sublinear 3mo ago
This is the only correct answer in this entire thread! Congrats!

dapperdrake 3mo ago

Computers are very good at repeating a known "recipe". They can add numbers billions of time per second. Yes, billions with a bee. The hard part is coming up with a recipe that solves your problem and that the machine can run without breaking things when it runs around with a few billion steps per second. You have to think ahead for it and handle edge cases in the recipe. That is the really hard part.

victorbjorklund 3mo ago

It is harder to do more with less. There is a reason React and other is used so much. Makes it easier to make interactive websites. It’s like asking why backend engineers think it’s harder to code an api using C instead of using Django.

acdha 3mo ago
I used to think that was true but I now think it’s only true for very interaction-heavy apps: if you have hundreds of interactions on a page over many minutes, using an SPA is amortized across a lot of time, but if it’s something you could do with e.g. a simple Django app you’ll not only be done faster but will spend an order of magnitude less time on maintenance and accessibility work.
- zelphirkalt 3mo ago
  That's usually not even in the books of a typical SPA: It doesn't have fallbacks at all, and just shows a blank white page. Accessibility is always taking a rear seat with such SPAs.
  - acdha 3mo ago
    It can be really difficult for people with screen readers: focus jumps, inconsistent update flow, too many or not enough announcements, etc. People just want to live their lives, not have to threaten 508 to be able to pay their cable bill as easily as it was 20 years ago.
- victorbjorklund 3mo ago
  Alright but Django isn’t a pure HTML file only solution. If you have a site with no interactivity it seems like Django is the wrong choice if everything is static.
  - acdha 3mo ago
    Who said it was? My point was simply that if you’re doing something like getting data in and out of a SQL database using web forms, you can avoid a ton of overhead and deliver a better user experience without using an SPA, and of course there’s a lot to be said for not needing to install security patches weekly due to having fewer, simpler moving parts.

pbalau 3mo ago

The short and sad answer is that most people that work in web development do not understand how the web works or how web apps work.

austin-cheney 3mo ago

[dead]

Traubenfuchs 3mo ago

Modern web/frontend devs do NOT understand whole page navigating form POST calls from a pre JS era.

meander_water 3mo ago

As someone who has built both react based frontends and html based ones (with htmx), there is a law of diminishing returns at play. To start off, writing a basic crud website with forms is much easier with htmx. But when you start building more complex components, and integrate with other systems (OAuth for e.g.) there are tons of libraries and SDKs for the react ecosystem, but not many for pure html components. At this point, it's much easier to use off the shelf components than it is to manually write html to handle all the bizarre UI edge cases.

meander_water 3mo ago
Really curious to understand why I'm being downvoted. I don't think it's a particularly spicy take - Just choose the right tool for the job.
- yurishimo 3mo ago
  I think a lot of people here don't seem to understand or appreciate the diversity of systems that "web developers" have to work in. Some people might say, "Why do you need all that oAuth complexity? Rip it out and use a cookie like God intended." We, the devs/ICs, don't often get to make those decisions. We're placed into teams working on specific features/apps/tools and we often have to integrate with a myriad of business systems by default. Yea, I would love to work on a simpler system, but I don't get to make that decision. Especially not when my company has been acquired by unbounded VC cash three times in the past 5 years and now I'm forced to fold in my lovingly crafted baby into the behemoth.

em-bee 3mo ago

my most recent website is fully static html and css. it contains several pages and a menu that is duplicated in all pages. that menu is maintained manually, and every time a page is added, all copies of the menu have to be updated. at some point that will get tedious. then i have a few options: i generate the menu using a backend framework. the downside: the website is no longer fully static. i now depend on a backend framework for hosting. static hosting is out. i also have to edit the content through the backend, and i have to continuously maintain the backend for the lifetime of the site. i generate the menu using a static site builder. the downside: i can no longer edit the content directly in html. i have to keep a source version for the static site generator, and more critically, i have to keep a copy of the site generator in my repo because i want to be able to make changes to this site 10 years from now and not find that the version of the site generator i was using is no longer available for download and my source is not compatible with the new version of the site generator. i generate the menu using xslt. works, but xslt is no better than javascript security wise. it's possibly even worse. and xslt support may be removed from browsers in the future. the final option is javascript. using some framework that doesn't need build tools, or something homegrown. i am afraid javascript is the only option that is futureproof while letting me avoid manual work to maintain the menu.

creesch 3mo ago
While purists will disagree, a little bit of javascript is fine. Having said that, you are talking about a personal website. Most companies will have a backend of some sort anyway. Also, here is a little secret. If you want something that is future proof, try something that has been around for decades and still runs large parts of the internet. People will scoff at this, but PHP is actually really neat for personal websites and has been for decades. A while ago I also found myself looking at static site generators, workflows from github to my host, etc. Eventually I realized I don't update things nearly enough, don't blog, etc. For similar reasons as you I didn't want to go completely static as that is just too much hassle when doing multiple pages. So I decided to utilize that good old lamp stack to basically do something like this. <?php $pages = json_decode(file_get_contents('pages.json'), true); $page = $_GET['page'] ?? 'home'; if (!isset($pages[$page])) { $page = 'home'; } $pageData = $pages[$page]; $contentFile = basename($pageData['file']); $contentFilePath = "content/{$contentFile}"; ?> <html> <head> <title><?= htmlspecialchars($pageData['title']) ?></title> </head> <body> <main> <?php include $contentFilePath; ?> </main> </body> </html> Slightly more, but the base principle is the same. Just 10 lines of php code, and now I can just add pages by uploading their contents and adding them to the json file for whitelisting. For your use case it would be trivial to add a menu based on the json file and I'd be confident that it will still work in 10 years with minimal adjustments. As a bonus I also rediscovered PHP in itself works really well as a templating language (as you can see) so no need for extra stuff like handlebars. As an extra extra bonus, I can just go to any shared webhosting party and get it running with no issue at all. I am not saying you'd need to go down this road. But I just want to illustrate how stupidly simple a website can be with "old" basic technologies even if you want some form of backend.

nailer 3mo ago

> Why is it more work? People expect the entire screen not to redraw whenever they interact with an app and expect behaviour asides from the HTML defaults.