Live data from Hacker News

Websites have evolved back to static HTML/CSS/JS files

paramaggarwal.substack.com

251–260 of 313 posts

Re: Websites have evolved back to static HTML/CSS/JS files

#251

> The Dark Age - Somewhere on this path to render pages on the fly (SSR) and render pages on the client (SPA) we forgot about the performance of our webpages. We were trying to build apps. But the web is about presenting content first and foremost! Pfff - That's completely wrong. SPAs are all about performance. If you want to built a highly-interactive site, it makes sense to do the computing where it's consumed -- i…

> Says who? Everyone who isn't only on the web to try to make money. That's who. But all you for-profit types are runining it. As the browser becomes more powerful it is more important to secure it. As security becomes more important features are removed and the browser begins telling the user what they can and cannot do. And on the webmaster side it becomes infeasible for browsers to display your site or search engi…

Ha. Who says you shouldn't try to make money on the web? This is a deeper argument about capitalism and exploitation of resources. Practically speaking, capitalism will always find ways to make profit from exploitable resources. If you don't like that, you have to change society.

Re: Websites have evolved back to static HTML/CSS/JS files

#252

There's nothing wrong with static HTML/CSS/JS. There's also nothing wrong with a rich SPA. And again, there's nothing wrong with using some kind of dynamic server-side HTML/CSS/JS presentation (like WordPress). Where there is a problem is the culture of software engineering, and the tendency to select the newest technology stack of the day for inappropriate applications. I think any seasoned software engineer has acq…

>Junior - mid engineers: EW WordPress! Doesn't that use PHP

I related too hard.

I had an intern say something like this but didn't give a reason. So I asked "why?". He couldn't give me an answer.

Re: Websites have evolved back to static HTML/CSS/JS files

#253

> The Dark Age - Somewhere on this path to render pages on the fly (SSR) and render pages on the client (SPA) we forgot about the performance of our webpages. We were trying to build apps. But the web is about presenting content first and foremost! Pfff - That's completely wrong. SPAs are all about performance. If you want to built a highly-interactive site, it makes sense to do the computing where it's consumed -- i…

Gmail is literally a document browser. I think Google Maps might be a better example.

Google Maps is definitely a great example. I chose Gmail as my example, because from what I've read, that's where XHR was born, which is what I view as the birth of web apps. It's the idea that you don't have to pull an entirely new document from a server to update a small part of the view. I think that transforms the web from a simple document transfer system into something capable of behaving like an application.

Re: Websites have evolved back to static HTML/CSS/JS files

#254
post #215

Earlier quoted context omitted.

This feels like a response from a seasoned backend engineer. Seasoned frontend developers value user experience and design — thus the tendency to go "back to static" and rarely back to WordPress.

To me Wordpress sounds exactly a suggestion you'd get from someone who doesn't have to maintain it. I.e. frontend dev.

Huh... Maybe I haven't done anything too complicated in WP, but I didn't find it bad.

Worst case I use a dedicated PHP page and MySQL. But in reality I think I usually put my code in functions.php(?) And it works fine.

Re: Websites have evolved back to static HTML/CSS/JS files

#255

> The Dark Age - Somewhere on this path to render pages on the fly (SSR) and render pages on the client (SPA) we forgot about the performance of our webpages. We were trying to build apps. But the web is about presenting content first and foremost! Pfff - That's completely wrong. SPAs are all about performance. If you want to built a highly-interactive site, it makes sense to do the computing where it's consumed -- i…

Update: OK, OK. I'm getting a lot of responses saying that Gmail is a bad example to use, because it's slow and bloated. I've responded to a few of those comments, but I think it should be addressed on a higher level.

To clarify, I said "Gmail showed us", because from what I've read, the early Beta releases are where XHR was born, which is what I view as the birth of web apps. It's the idea that you don't have to pull an entirely new document from a server to update a small part of the view, which translates into a more seamless experience typical of native apps. I think that transforms the web from a simple document transfer system into something capable of behaving like an application.

I think the explosion of JS frameworks since then are about how to effectively manage the use of XHR to update the view.

Re: Websites have evolved back to static HTML/CSS/JS files

#256
post #238
post #232

Earlier quoted context omitted.

We're back to "The boring solution has a long list of inconveniences and uglinesses that everyone knows about. If we chose the new solution, nobody would know where the bugs are and we can have exciting new ones." Really the problem is that the standard solution hasn't improved. Backends are still a hassle in the 2020s. People keep reinventing CGI. Every now and again I think "why doesn't someone just produce a simpl…

Backends are still a hassle? In what way do you feel Spring (Boot), ASP.NET Core and the like don't solve the problem adequately?

You still have to write one at all? And it's an entirely separate process from the frontend, and usually in an entirely different language? And many places hire different developers to do it?

Maintaining a static site is easy and places like github pages will host it for free; you can put a "SPA" in there if you like for no additional cost. But as soon as you need a backend it gets more complicated and expensive. Still cheap in absolute terms, but relatively more complicated. Oh and you need to keep an eye on it for security. I know the long list of reasons for this situation, but I'm questioning why it has to be this way.

Back in the 80s there were proprietary monolithic single-user systems for producing what were effectively interactive databases, such as dBase and FoxPro. There was also the legendary programmable hypertext system HyperCard. And yet developing a small web application to do something that could be knocked up with a few screens of dbase or hypercard is much more time-consuming.

Re: Websites have evolved back to static HTML/CSS/JS files

#257

No, the SPA hype has warn off and people realize that although these new technologies exist, they are not always needed. If you are building a web app, use React or similar. If you are building a web site, use plain HTML+CSS w/ supplemental JS. Sometimes your project can be split in half. Do the landing page, signup, login, privacy policy, etc. in plain HTML. Maybe don't embed all that stuff in your app and you would…

> If you are building a web app, use React or similar. I disagree with this, there's no reason to use React/Vue/Angular for a web app by default. And I would urge people to try and avoid it for as long as possible and see how far you get. From personal experience I can tell you that most of the time, you don't need a frontend framework to build a web app.

From my professional experience throughout the last decade, you're wrong.

I urge people to practice and use the best tool for the job, don't avoid something because some hipster thinks it's too popular.

Feel free to go back to jQuery spaghetti code, it's nice until you build something too big.

React isn't a framework btw, it's just the view. You can stack anything or nothing with it.

Re: Websites have evolved back to static HTML/CSS/JS files

#258

There's nothing wrong with static HTML/CSS/JS. There's also nothing wrong with a rich SPA. And again, there's nothing wrong with using some kind of dynamic server-side HTML/CSS/JS presentation (like WordPress). Where there is a problem is the culture of software engineering, and the tendency to select the newest technology stack of the day for inappropriate applications. I think any seasoned software engineer has acq…

I get what you say but WordPress is a weak example. It's so fragile security wise (especially if some plugin holds you back on updates).

Re: Websites have evolved back to static HTML/CSS/JS files

#259

There's nothing wrong with static HTML/CSS/JS. There's also nothing wrong with a rich SPA. And again, there's nothing wrong with using some kind of dynamic server-side HTML/CSS/JS presentation (like WordPress). Where there is a problem is the culture of software engineering, and the tendency to select the newest technology stack of the day for inappropriate applications. I think any seasoned software engineer has acq…

the issue is that younger people want to do the use and learn the newest thing to advanced their careers, while us old timers just want to get shit done. you can't blame them, we we're all like that at one point, it's why we got into programming to begin with.

this is one reason why i fully believe companies should have a give each developer a half-day or day to work on new thing for the company so that new developer get to scratch that itch without trying to force using something new just for the sake of using something new.

Re: Websites have evolved back to static HTML/CSS/JS files

#260
post #232

There's nothing wrong with static HTML/CSS/JS. There's also nothing wrong with a rich SPA. And again, there's nothing wrong with using some kind of dynamic server-side HTML/CSS/JS presentation (like WordPress). Where there is a problem is the culture of software engineering, and the tendency to select the newest technology stack of the day for inappropriate applications. I think any seasoned software engineer has acq…

We're back to "The boring solution has a long list of inconveniences and uglinesses that everyone knows about. If we chose the new solution, nobody would know where the bugs are and we can have exciting new ones." Really the problem is that the standard solution hasn't improved. Backends are still a hassle in the 2020s. People keep reinventing CGI. Every now and again I think "why doesn't someone just produce a simpl…

> "The boring solution has a long list of inconveniences and uglinesses that everyone knows about. If we chose the new solution, nobody would know where the bugs are and we can have exciting new ones."

Is this C vs Rust again? (it's a joke, but go ahead, downvote).

Post reply on HN