Live data from Hacker News

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

paramaggarwal.substack.com

81–90 of 313 posts

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

#81
post #74

Hell, I still write the HTML and push it to Github where Github Pages and Cloudflare put it up on the Web for me. I've never seen any reason to use Markup when I can just Mark my text Up in HTML pretty simply. If you write a site correctly (a site, not a webapp) it'll render in anything from the original Netscape to the Wii Browser (tested working with my site), Internet Explorer 8 (working), Links2 (working), and th…

> Hell, I still write the HTML and push it to Github where Github Pages and Cloudflare put it up on the Web for me. I've never seen any reason to use Markup when I can just Mark my text Up in HTML pretty simply.

This sounds like you're making everything more difficult for yourself with little to no gain whatsoever.

With Markup or Markdown, you're still writing that HTML, but you're writing it once and then using automation and data structures to abstract it away. After that's implemented, and it's already been done for you (Hugo, MkDocs, ...), you're just writing the actual content and using simple syntax to format it. Everything else is then handled for you.

I wrote this recently: https://www.thecloud.coach/terraform/understanding-state/

If I had to write that from first principles, as you're doing above, I simply wouldn't have.

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

#82
post #20

Earlier quoted context omitted.

The trend in my work is to add more and more JS to get the render time below 11ms per frame (11ms for my code, plus 5ms for the browser to paint and update, for a solid 60fps). To do that takes a lot of data structure design, memoization, cache management, plus a decent understanding of how browsers put things in the DOM and on the screen. Admittedly I work on something that's a bit unusual (a diagram tool for lawyer…

Why would you ever build that kind of application using web technologies?

Simple: every machine has already installed the gateway to your program: a web browser. No need to deal with issues like antivirus going bonkers, weird MSVCRT versions installed leading to support requests, you save a ton of money when you need to support OS X or god forbid Linux, and last but not least, an SaaS business model has recurring revenues while it doesn't have to deal with rampant piracy at the same time.

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

#83

Earlier quoted context omitted.

> But Gmail showed us that web 'apps' are useful. Gmail is terrible. It's slow and most people prefer the static html version.

> It's slow and most people prefer the static html version. The only people I've ever heard talk about the static html version are a few HNers. I'd wager 99% of people don't care, don't mind their email client's first load being slow (they just keep it open in a tab anyways), and don't even know about the static html version.

Most people know Google’s webapps are slow, they just don’t know how to do anything about it. Or they notice it as worse battery life and fans running constantly and think there’s something wrong with their laptop because they don’t realize a web app can cause that, or even know what a webapp is.

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

#84
post #74

Hell, I still write the HTML and push it to Github where Github Pages and Cloudflare put it up on the Web for me. I've never seen any reason to use Markup when I can just Mark my text Up in HTML pretty simply. If you write a site correctly (a site, not a webapp) it'll render in anything from the original Netscape to the Wii Browser (tested working with my site), Internet Explorer 8 (working), Links2 (working), and th…

I have no idea what your site is about. Its just random links with no explanation about what they are or for.

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

#85
I think we just all have to agree that plugging a complex, dynamic component into a web site should be done with care and attention to the details.

If you need to offer some dynamic element to your website, such as a form that does validation, then just add a form that does validation with the most minimal of code, bloat and everything else.

Why is this hard?

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

#86
post #34
post #30

Earlier quoted context omitted.

> But Gmail showed us that web 'apps' are useful. And we really have come full circle. Gmail performance, at least on Firefox, is awful.

Its performance is so horrible that even on a high spec machine with fast internet, you have plenty of time to click the "switch to plain ol html" button. Which is actually more in line with the performance I'd expect from a glorified file drawer.

Loads instantly for me on FF desktop and laptop running linux. But i have experienced what youre talking about.

You either have graphics hardware support disabled or youre laptop CPU is not running in perfoance mode and has its govenor set to something like balanced or power saving mode.

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

#87

> 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…

> Use the right technology for what you're trying to build.

Yep .. so if you want a rich responsive user experience, DON'T use any web technologies. GMail (AND Gsuite) is a perfect example of how a relatively simple concept like email can be turned into a slow, unresponsive piece of garbage.

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

#88

Earlier quoted context omitted.

> It's slow and most people prefer the static html version. The only people I've ever heard talk about the static html version are a few HNers. I'd wager 99% of people don't care, don't mind their email client's first load being slow (they just keep it open in a tab anyways), and don't even know about the static html version.

Most people know Google’s webapps are slow, they just don’t know how to do anything about it. Or they notice it as worse battery life and fans running constantly and think there’s something wrong with their laptop because they don’t realize a web app can cause that, or even know what a webapp is.

> Most people know Google’s webapps are slow

Can you substantiate this with more than just your personal experience? This doesn't match my experience outside of the HN bubble.

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

#89
post #7

Earlier quoted context omitted.

Jesus, why? You could write the back end in something that isn’t fucking garbage, at that point.

This is just empty negativity. That people use Javascript in places they aren't forced to use Javascript should make you wonder what the upsides are for them instead of assuming they cannot form any valid preferences of their own, unlike yourself. For example, Javascript is one of the few languages that actually delivers on "async everything" and has a very simple Promise abstraction (like Promise.all()), and that ma…

Maybe the problem here is building networked services (sounds like synchronous communication between components). How often is it that a well architected microservice architecture needs to do more than push data into a decoupling resource and data store and consume data from a stream or a queue? Is Promise.all( ... ) really that relevant that often?

I've come to enjoy Node.js more than I thought I ever would, but it's still not something that's ever mindblowing to me, and I don't think that switching to Python would be a huge burden. With sensible tooling and contracts, neither would switching to a statically typed backend.

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

#90
post #86
post #34

Earlier quoted context omitted.

Its performance is so horrible that even on a high spec machine with fast internet, you have plenty of time to click the "switch to plain ol html" button. Which is actually more in line with the performance I'd expect from a glorified file drawer.

Loads instantly for me on FF desktop and laptop running linux. But i have experienced what youre talking about. You either have graphics hardware support disabled or youre laptop CPU is not running in perfoance mode and has its govenor set to something like balanced or power saving mode.

...why is a web-based email client depending on graphics hardware?
Post reply on HN