> On the frontend, you have build pipelines, bundlers, CSS frameworks with their own toolchains, progressive web apps, Core Web Vitals, SEO, layout shifts, srcset/responsive images… I remember when the biggest challenge was IE6 compatibility.

You only have those things if you choose to use them.

I've been building websites for 25 years. I use the same core technologies today that I did when I started. Sure, I make use of modern improvements to the languages themselves, but I have never permanently adopted any of the "hot new trends" and feel I am better - or at least saner - for it.

No, your marketing or e-commerce website almost certainly doesn't need a JS bundling toolchain. It almost certainly doesn't need a CSS preprocessor or even a CSS boilerplate/framework. It almost certainly doesn't need an enterprise-class PHP framework; or a dependency manager; or a CI/CD pipeline.

▲

Jaygles 3 days ago | parent | next [-]

Those technologies don't just solve tech issues, they solve organizational issues. If one or two people manage a website, going without fancy tooling is completely fine. When 1000 people are managing a product with complex business logic across multiple platforms, you need fancy tooling to ensure everyone can work at a reasonable level of productivity.

	▲	acdha 3 days ago \| parent \| next [-]
		> you need fancy tooling to ensure everyone can work at a reasonable level of productivity. If you have a thousand people working on a single product, yes, but you also have the resources to have dedicated tool support teams at that level. In my experience, if you’re under multiple dozens of developers or not everyone works on all of your projects, the tools fragment because people aren’t combining or configuring them the same way and there’s enough churn in the front-end tool space that you’ll hit various compatibility issues which lower the effectiveness of sharing across projects. This is especially true if you’ve hired people who self-identify as, say, Next or Tailwind developers rather than web developers and lack the understanding of the underlying technology to fix complex problems.
	▲	rendaw 3 days ago \| parent \| prev \| next [-]
		The article is about developing as a solo developer.
	▲	marcosdumay 3 days ago \| parent \| prev \| next [-]
		> build pipelines, bundlers, CSS frameworks with their own toolchains, progressive web apps, Core Web Vitals, SEO, layout shifts, srcset/responsive images Build pipelines are purely a technical decision. Bundlers are purely a technical decision (TBH, a non-brainer if you decide to have a build pipeline, but it's not an organizational helper). Those help one do some things, not several people to organize. I'm still waiting for any person to claim they made CSS maintainable by adopting a framework. It's an almost purely organizational decision with no upsides at all. PWAs are a product decision, not technical or organizational. The same applies to Core Web Vitals, SEO, layout shifts and srcset, those are all product decisions. You can escape the technical and organizational decisions. You can't escape the product ones.
	▲	austin-cheney 2 days ago \| parent \| prev [-]
		This is why web development stopped being fun: developers that cannot manage or train people and instead hope garbage like jQuery will simply act as a surrogate parent.

▲

ifh-hn 3 days ago | parent | prev | next [-]

What are you using? If you don't mind me asking.

▲

sublinear 3 days ago | parent | prev [-]

It's so weird to see this take repeated over and over. I have to assume you have never written a large scale project for the web? The only part where I agree is that you don't need PHP or server-side rendering in general.

▲

Aldipower 3 days ago | parent | next [-]

Nowhere he talked about large scale projects and the article neither btw. I am sure his choices are different when working on a large scale project.

▲

wesammikhail 3 days ago | parent | prev | next [-]

> I have to assume you have never written a large scale project for the web?

Can I ask, what classifies as large scale project for the web?

I previously created and exited a trading platform that did billions in transactions via our servers with thousands of users streaming real time data. It's certainly more complicated and "larger" than 99.9% of things you'll ever do. So does that qualify?

If so, I can tell you that I did it with PHP and no JS frameworks. Hosted on a couple of VPS servers from digital ocean. From idea to execution to exit in ~9 months.

You know what the weird part is? I see your take repeated over and over by "shovel peddlers" and grifters. And every single time it comes with 0 substance or merit.

▲

vanviegen 3 days ago | parent | next [-]

> I can tell you that I did it

The 'I' here reveals that this is indeed not a large scale project, though perhaps impressive. When working on a piece of software with tens of people, using more tooling really does makes sense.

▲

timeon 3 days ago | parent [-]

'I' here reveals that it is on topic in context of posted article. Which is purpose of this thread.

Sorry I do not want to sound like a dick re-stating the obvious but threads often are going off the rails and I find it bit absurd.

	▲	vanviegen 2 days ago \| parent [-]
		I've tried to parse your comment from various perspectives, but can't seem to make sense of it. A 9-person-month project is just not a large scale project by any definition.

▲

2 days ago | parent | prev | next [-]

[deleted]

▲

sublinear 2 days ago | parent | prev [-]

Congrats to you, but yeah the other comments have already said it.

I'm talking about projects that have a lot of people working together across multiple teams where not everyone is even a dev. This is routine with e-commerce. The build will have assets from design teams, copywriters, analytics scripts, etc. and a CMS isn't always the correct or even scalable solution for that. The original commenter I was replying to seems to be stuck in the past. These days it can all be done with a simple CI script, but yeah ultimately that means build tools.

Above all else, like I said in another comment, there cannot be server-side rendering because it deploys to a CDN for hosting. These are projects that require huge amounts of content, but need to stay responsive. The final build result and upload is many files, but the initial load for the site is minimal JS and HTML to render for the user.

> billions in transactions via our servers with thousands of users streaming real time data. It's certainly more complicated and "larger" than 99.9% of things you'll ever do.

Large scale doesn't have to be complicated, but it does need some way to coordinate the effort which means there's a build and there will be requirements that are beyond any one person's control and expected for the modern web.

I want to also point out the obvious that there's insane money being made in e-commerce since it's now the default way to shop for everyone. It's a very common type of web project and if the typical HN web dev is getting paid a decent salary it's likely that the sites they maintain have several orders of magnitude more users than what you're talking about.

▲

user34283 3 days ago | parent | prev [-]

I used to think the same about server-side rendering until I more closely looked at React SSR.

I think it makes a lot of sense and allows for faster initial rendering of the page while automatically setting up the JS and interactivity in the background.

▲

sublinear 3 days ago | parent | next [-]

Couldn't you just static render the parts that you're using SSR for?

I am not trying to be dismissive, but a common strict requirement is static hosting from a CDN, embedded environments, etc.

▲

user34283 3 days ago | parent [-]

If you static render, it won't be an interactive application.

With React SSR you get the best of both: stream static HTML chunks immediately, and rehydrate with JS later, prioritizing components the user interacts with.

It should load quicker compared to traditional React apps where the browser loads the HTML, then loads the JS bundle, and only then renders a loading skeleton while likely triggering more requests for data.

▲

zarzavat 3 days ago | parent | next [-]

> It should load quicker compared to traditional React apps where the browser loads the HTML, then loads the JS bundle, and only then renders a loading skeleton while likely triggering more requests for data.

Then your JS bundle is broken.

Promises exist. Modules exist. HTTP/2+ exists. You can load data while you are loading a small amount of JS required to render that data while you are loading other parts of your JS.

If everything is sequential: load giant JS bundle -> fetch -> render, that's because someone architected it like that. Browsers give you all the tools you need to load in parallel, if you don't use them then it's not the browser's fault.

You do not need SSR or rehydration. That's just Vercel propaganda. They saw that people are doing a stupid thing and decided to push a complex solution to it. Why? It makes them money.

▲

user34283 3 days ago | parent [-]

You cannot load any data in a regular React application before you loaded both React and your React components that trigger the fetch.

If you use code splitting, your initial bundle size can be smaller, yes. That's about it.

I guess in theory you can hack together static loading skeletons that you then remove when React loaded your initial bundle, but that's certainly far from a common approach. By that standard, the vast majority of JS bundles would be "broken".

	▲	zarzavat a day ago \| parent [-]
		> You cannot load any data in a regular React application before you loaded both React and your React components that trigger the fetch. You totally can! Don't call fetch directly from a component - it's brittle. Write a hook to abstract that into one place. In your hook you can support prefetching by awaiting the promise you fired before you loaded your JS bundle (if you don't want to modify the server), or else take advantage of the browser cache. In this way your data and code can load in parallel. Is it common? Not really. But it's a technique that is in the toolbox of a conscientious webdev.

▲

sublinear 3 days ago | parent | prev | next [-]

Static rendering has nothing to do with interactivity in a web app.

I guess if you're already so deeply entrenched in writing all your application logic on the server side you need React SSR, but that sounds miserable.

▲

DrammBA 3 days ago | parent | prev [-]

You seem to be confused about your terms, both SSR and SSG can rehydrate and become interactive, you only need SSR if you have personalized content that must be fetched on an actual user request, and with frameworks like astro introducing island concept it even let's you mix SSG and SSR content on a single page.

▲

user34283 3 days ago | parent [-]

That depends on how you interpret "static render".

I did not interpret that as React SSG. SSG is the default behavior of NextJS unless you dynamically fetch data, turning it into SSR automatically.

What I thought of is React's "renderToString()" at build time which will produce static HTML with event handlers stripped, in preparation for a later "hydrateRoot()" on the client side.

	▲	DrammBA 2 days ago \| parent [-]
		> That depends on how you interpret "static render". It only depends if you interpret it incorrectly.

▲

williamcotton 2 days ago | parent | prev [-]

React has always supported server-side rendering and there have been many tools over the years to "rehydrate" data from the server to the client for when the client-side React application "takes over".