Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

paramaggarwal.substack.com

Post reply on HN
Print view View original

31–40 of 313 posts

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

#31

Post by hombre_fatal »

ehvatum wrote: post #7
Spivak wrote: post #4

Earlier quoted context omitted.

The JAM stack the author is talking about is entirely driven by JS. The is “static” in the sense that a .dmg file is static and can be hosted on a CDN and not templated on the server.

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 makes it better for me than building networked services in similar languages (PHP, Python, Ruby). It's also one of the few dynamically-typed languages with a bolt-on static type system that actually gained traction.

You might not care about these things somehow, like maybe you only write C and Python because you work with embedded systems. But I think it's time to stop calling it garbage in honest conversation.

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

#32

Post by saagarjha »

qznc wrote: post #22
camccar wrote: post #18

Earlier quoted context omitted.

New reddit is painfully slow to login. So much javascript for a simple dialog to load it's absurd.

As long as old and compact reddit are still there, I'm fine with it. Twitter on other hand has no lightweight version, unfortunately.

I think I recall someone mentioning there is one that you get if you send an empty User-Agent.

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

#33

Post by chmod775 »

x3haloed wrote: post #23

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

> But Gmail showed us that web 'apps' are useful.

Gmail is terrible. It's slow and most people prefer the static html version.

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

#34

Post by eyegor »

amluto wrote: post #30
x3haloed wrote: post #23

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

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

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

#35

Post by satya71 »

chmod775 wrote: post #33
x3haloed wrote: post #23

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

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

Somehow everyone I know is happy with GMail and find a full-featured email client incomprehensible. I can't stand GMail's slow UI.

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

#36

Post by warent »

chmod775 wrote: post #33
x3haloed wrote: post #23

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

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

As much as I advocate for web apps, sadly I have to agree with this, gmail is maybe one of the worst examples to use. Especially once they launched the new experience, the performance has been god awful. And frankly thats part of the reason I refuse to use Angular if the company that designed it cant even optimize it properly.

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

#37

Post by SquareWheel »

geggam wrote: post #12
AdmiralAsshat wrote: post #2

Good. I could do without the JS, to be honest (I'm a little tired of pages that refuse to show me anything unless I whitelist some stupid third-party jQuery script in uMatrix), but, baby steps. When sites finally ditched their trendy Flash rewrites and went back to HTML, I thought, thank God .

Be interesting to see if we could start charging website owners fees for them using our processing power to render their site. Something needs to be done to encourage some efficiencies given the fact it takes more resources to surf the internet and read about running a k8s cluster than it does to actually run the cluster

Would you pay their fee for generating the page on the server?

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

#38

Post by geggam »

SquareWheel wrote: post #37
geggam wrote: post #12

Earlier quoted context omitted.

Be interesting to see if we could start charging website owners fees for them using our processing power to render their site. Something needs to be done to encourage some efficiencies given the fact it takes more resources to surf the internet and read about running a k8s cluster than it does to actually run the cluster

Would you pay their fee for generating the page on the server?

I do

Netflix, Prime Video etc etc

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

#39

Post by hombre_fatal »

chmod775 wrote: post #33
x3haloed wrote: post #23

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

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

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

#40

Post by hombre_fatal »

geggam wrote: post #25
p2t2p wrote: post #15

Earlier quoted context omitted.

You're free not to use any website...

Arguably if you are publishing content on the net you are giving it away. There are mechanisms to charge for it.

> There are mechanisms to charge for it.

Only above a certain price point. Our financial system nor our consumer culture support micropayments yet. This effectively limits the web properties that can charge users to a small fraction, so unfortunately "just charge money" isn't the widely-available solution I wish it was yet.

Hell, it's more viable to charge users for your mobile client than the backing service. It's kind of the closest we have to micropayments in a way.

Post reply on HN