Live data from Hacker News

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

paramaggarwal.substack.com

271–280 of 313 posts

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

#271

Earlier quoted context omitted.

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.

Microsoft developed XHR in 1999 to support Outlook on the web.

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

#272

Earlier quoted context omitted.

Netlify and Jekyll are kind of more oriented towards develoeprs, not Janine in reception. Regarding WordPress and plugins:

I'd rather Janine ping me three times a year to change some string than deploy PHP with mysql.

Php with mysql is amazing. I don’t get the “i’d rather have Janine ping me three times an year”. What if you leave work? What if you are too busy with your next hobby project that you don’t give a shit about Janine? What if she wants to update brochures every now and then and your manager says you’re too expensive to help Janine.

Tech is about automation. Php + mysql still serves well in this era. Wikipedia still runs on it and it’s a pretty fantastic and responsive site. So does Facebook to some degree I suppose.

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

#273
post #260
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…

> "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).

Oh, it's practically general purpose life advice. You could even apply it to some people's second marriages.

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

#274
post #75

Earlier quoted context omitted.

> I doubt I'll ever voluntarily use one of those frameworks for web dev. > I do, however, like this thing called, Svelte. Svelte is just another one of “those frameworks”, except with a vastly smaller community: https://trends.google.com/trends/explore?geo=US&q=svelte%20i...

And without a virtual dom and all of its overhead.

Virtual dom isn’t that expensive compared to modifying dom. Svelte isn’t magical, it’s still diffing objects to figure out whether to change some dom element’s attributes

With react memoization and pure components, you get very similar benefits.

Sure svelte goes the extra step and removes unnecessary diffing of constant attributes that will never change and other opts. However there are tradeoffs

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

#275
post #67

Earlier quoted context omitted.

"Single page" isn't the why it's the how. It enables you to take a JavaScript-first approach which in turn makes building complicated applications easier.

> It enables you to take a JavaScript-first approach Uh-huh... > which in turn makes building complicated applications easier. What? This is vacuous market-speak.

SPA gives you all the state stored client side, backend can be reduced to simple stateless functions. Anything persisted longer goes in the DB, and plenty of solutions exist that automatically keep the client side view of the DB and the backend in sync automatically, even across temporary loss of connectivity.

Compared to the bad days of server side session management, SPAs are far simpler to code and to reason about.

The elimination of the back and forth between client and backend means far less testing, and far simpler testing.

It is also arguably more efficient. Yes it uses more resources on the client compared to doing everything server side, but cpu and memory needs to be used no matter what. Treating web browsers as dumb terminals when the cheapest smartphone is at least quad core is a bit silly.

That said, there isn't any excuse for bad client side code that murders CPUs, but not using the client for anything but JPEG decoding doesn't make much sense!

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

#276
post #199

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'm not sure it's junior/senior so much as personal taste: Plenty of junior engineers use Vim and Emacs, neither of which are trendy in any meaningful way, and I'm sure there are senior engineers who use Visual Studio with all of its whiz-bang. Similarly with websites, some have ideas which need AJAX and, possibly, WASM, and others have ideas which need static sites or, at most, "slightly dynamic" websites with only…

> Plenty of junior engineers use Vim and Emacs

Pretty sure that’s not the case anymore, I have been a developer for 3 years and have never ever seen anyone use either of these for work

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

#277
post #49

If SPAs are the dark ages then what do you call the IE6/7 jQuery days?

The Wild Wild West!!? I remember doing jquery/ajax calling an API and while it was easy to churn out spaghetti or long js file code, it was still easier to read and pick up a few years later.

> it was still easier to read and pick up a few years later.

Compared to what?

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

#278

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…

>Seasoned engineer: Let's use any well-tested CMS such as WordPress and install a caching front-end.

I thought that was your junior response... you update it once a month, seems like WordPress is seriously overengineered for something managed internally. Static website + a 1h ticket once a month seems much better.

You'll save in performance, security, and it over a few years, it would take you less work time than doing a full WordPress.

If it's more than once a month, now it may be more interesting to go toward a WordPress, but that would be doubtful.

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

#279
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?

Oh gosh Spring Boot is such a dumpster fire. Dont even pretend its good!

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

#280

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 think any seasoned software engineer has acquired the skill of successfully selecting the correct architecture for the project goals (even if it is _boring_ to actually work on).

Some experienced developers get it, but I have argued with plenty who are busy keeping up with the hype cycle and resume driven development.

Post reply on HN