> put text on screen

I get where you're coming from but that's actually quite a bit of an oversimplification even for many web apps outside of the 1% for which a lot of modern web development solutions and frameworks seem to have been created.

For one thing it doesn't take any account of input. When someone draws something with Figma or writes something in Google Docs or buys something from Amazon - or indeed any online shop at whatever scale - or gets a set of insurance quotes from a comparison site or amends something in an employee's HR record or whatever it may be the user's input is a crucial part of the system and its behaviour.

For another, we're not just putting text on the screen: we're putting data on the screen. And whilst data can always be rendered as text (even if not very readably or comprehensibly), depending on what it represents, it can often be more meaningfully rendered graphically.

And then there are integrations that trigger behaviour in other systems and services: GitHub, Slack, eBay, Teams, Flows, Workato, Salesforce, etc. Depending on what these integrations do, they can behave as inputs, outputs, or both.

And all of the above can result in real world activity: money is moved, orders are shipped from warehouses, flow rates are changed in pipelines, generators spool up or down, students are offered (or not offered) places at universities, etc.

If you reduce things so much that all detail is lost, you can't really reason about the original thing any more. The obvious counterpoint here is, you try turning amazon.com into a plain TXT file and see how much sales increase.

What kind of answer would you expect to a question like that? I couldn't tell you how much time and money I save writing in a programming language instead of raw machine code but I can rest assured that it's the right call.

Are people on this site just stuck in the 90s or something? The product I work on is nowhere near Figma or Google Docs level of complexity, but we're still MILES away from "just rendering text on screen".

That's about as absurd a statement as saying all of Backend is just "returning names matching a certain ID" for how out of date and out of touch it is.

I know two reasons for server-side rendering: (1) site indexing, (2) time to first screen update. With faster networks and client devices (2) isn't as important as it used to be.

The reasons I prefer client-side rendering: (1) separation of concerns UX in the front, data/business in the back (2) Even as a back-end dev, prefer Vue to do front-end work rather than rendering text + scripts in the backend that run in the browser, (3) at scale it's better to use the client hardware for performance (other than initial latency).

Are people going on with an estimate of how much time and money a specific tech stack saves? You come up with a number for this and it's accurate, I assume. Like if I were to say Node+TypeScript+Express vs. Golang you'd have an answer. If you get that right more often than not then the answer is you're really good at it in a way most people aren't.

But you are not just putting text on screen. That is a drastic simplification. To put text on screen, we had TV teletext/videotext. You can also just put a .txt file as your index.txt and serve that as your website. Or create a PDF from your word document. You won't need any developers at all for that.

I don't think any business goal of anywhere I've worked for the past 10 years has been "put text on a screen". It's usually more like, "interactive application that can view and manage complex data representations in intuitive ways". Charts, forms, graphs, error validation, nested tables, consistent styling, nice animations are all vital components that are much much easier with a modern web tech stack.

> The answer is always: put text on screen.

I wonder how you'll handle image uploading, drag and drop, media players, etc with simple static content rendering.

This is overly reductive. Sure, you can say all webdev does is put letters on screen. Oh, and graphics - don't forget about those. Just letters and graphics! Oh wait, that actually describes everything anyone has ever coded.

It's like saying that the entire job of a politician is to speak words out loud. You're reducing a complex problem to the point that meaningful discussion is lost.

“Always” is doing a lot of heavy lifting there. At my last few jobs the goals have involved interactive visualizations, 3D model viewers and peer-to-peer screen sharing. There is a huge diversity of business goals outside of things that can be reduced to “put text on screen”.

I mean LLM is also putting text on screen...