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

In Defense of the Modern Web

dev.to

Post reply on HN
Print view View original

21–30 of 224 posts

Re: In Defense of the Modern Web

#21

Post by ss3000 »

timw4mail wrote: post #7
jaywalk wrote: post #5

Earlier quoted context omitted.

A full-page refresh when I vote on a comment would be jarring. That's what he's saying.

If it works without JS enabled that way, but works the current way with JavaScript, what's the problem?

As far as I'm concerned, the problem is the people who choose to disable JavaScript and demand to be catered to without considering how much extra development resources I'd have to allocate to maintain a version of my app that works with JavaScript disabled, despite barely even constituting a rounding error in my usage statistics, and the JavaScript version offering a vastly superior experience for the rest of my users.

Re: In Defense of the Modern Web

#22

Post by quantummkv »

> When I tap on a link on Tom's JS-free website, the browser first waits to confirm that it was a tap and not a brush/swipe, then makes a request, and then we have to wait for the response. With a framework-authored site with client-side routing, we can start to do more interesting things. We can make informed guesses based on analytics about which things the user is likely to interact with and preload the logic and data for them. We can kick off requests as soon as the user first touches (or hovers) the link instead of waiting for confirmation of a tap — worst case scenario, we've loaded some stuff that will be useful later if they do tap on it.

What? The solution to making a website fast is to crunch analytics (presumably on the client and in JS, all of which has to be loaded beforehand for this to work) and then try to predict what the user is going to do on the website, anticipate it, and start loading, even when it might go waste?

Wastage of network bandwidth aside, Speculative Execution destroyed the chip performance in the last two years and opened up a whole lot of scary security holes, some of which may never be fully patched without performance hits. And the bright idea is to do that in the browser?

Re: In Defense of the Modern Web

#23

Post by zozbot234 »

rich_harris wrote: post #8
jaywalk wrote: post #5

Earlier quoted context omitted.

A full-page refresh when I vote on a comment would be jarring. That's what he's saying.

Or when I click the 'reply' button to post this very comment, which does result in a jarring full-page refresh — and one that instantly robs me of the fuller context in which I'm replying.

But this gives you the option of opening the reply link in a background tab (via click-and-hold or middle-click, depending on your UI). Can't do that in a JavaScript SPA without re-hydrating tens of megabytes of JS for each tab you load.

Re: In Defense of the Modern Web

#24

Post by timw4mail »

speedgoose wrote: post #10
grey-area wrote: post #3

This author seems to think the only competitor to react is other js frameworks, when in fact most of the web's largest sites work just fine with small amounts of what he calls 'artisanal js'. You probably don't need your js framework, your 10k npm dependencies, or your complex mix of server and client side rendering. Not every website needs an api and clients to consume it, and not everything needs to be an app. The…

The web is not only html documents rendered server-side though. You need much more advanced interactions.

I keep hearing this, but I think it's too broad of a statement.

There are definitely functionalities that are impractical to implement with server-side rendering and forms alone. Map widgets and drag-and-drop come to mind.

The issue I have though, is that the overwelming majority of web functionality can be implemented as server-side rendering.

Re: In Defense of the Modern Web

#25

Post by tashoecraft »

rich_harris wrote: post #8
jaywalk wrote: post #5

Earlier quoted context omitted.

A full-page refresh when I vote on a comment would be jarring. That's what he's saying.

Or when I click the 'reply' button to post this very comment, which does result in a jarring full-page refresh — and one that instantly robs me of the fuller context in which I'm replying.

Agreed, I’ve often opened another tab, found the context of the comment I’m replying to and hopped back and forth. HN can be an echo chamber of JavaScript is the devil, websites should only serve html.

Re: In Defense of the Modern Web

#26

Post by [deleted] »

grey-area wrote: post #3

This author seems to think the only competitor to react is other js frameworks, when in fact most of the web's largest sites work just fine with small amounts of what he calls 'artisanal js'. You probably don't need your js framework, your 10k npm dependencies, or your complex mix of server and client side rendering. Not every website needs an api and clients to consume it, and not everything needs to be an app. The…

[deleted]

Re: In Defense of the Modern Web

#27

Post by speedgoose »

timw4mail wrote: post #24
speedgoose wrote: post #10

Earlier quoted context omitted.

The web is not only html documents rendered server-side though. You need much more advanced interactions.

I keep hearing this, but I think it's too broad of a statement. There are definitely functionalities that are impractical to implement with server-side rendering and forms alone. Map widgets and drag-and-drop come to mind. The issue I have though, is that the overwelming majority of web functionality can be implemented as server-side rendering.

Even HN would have a poor usability with only server side rendering.

Re: In Defense of the Modern Web

#28

Post by swah »

rich_harris wrote: post #14
grey-area wrote: post #3

This author seems to think the only competitor to react is other js frameworks, when in fact most of the web's largest sites work just fine with small amounts of what he calls 'artisanal js'. You probably don't need your js framework, your 10k npm dependencies, or your complex mix of server and client side rendering. Not every website needs an api and clients to consume it, and not everything needs to be an app. The…

> your 10k npm dependencies Believe me, you're preaching to the choir. Nor am I advocating for every website to have an API. But unfortunately we part ways here: > The web is a success The web is not a success. It's dying. Consumers vastly prefer native apps — one recent study ( https://www.mobiloud.com/blog/mobile-apps-vs-the-mobile-web/ ) tells us that 90% of mobile time is spent in apps vs 10% in browsers.

We can make those with JS/React so I wonder if users can tell. Of course the hugely popular, cross-platform apps are probably going to be "really native" forever..

Re: In Defense of the Modern Web

#29

Post by realharo »

timw4mail wrote: post #13
echelon wrote: post #9

> The fact that we can do server-side rendering and communicate with databases and what-have-you using a language native to the web is a wonderful development. The author isn't just a React apologist, but also seems to want javascript everywhere. So much of this debate - sever side rendering, etc. - has to do with the inefficiency of DOM. Mobile and desktop UI toolkits aren't DOM for a reason. They do application UI…

I don't think the DOM is the bottleneck as much as JavaScript is.

Based on what?

Re: In Defense of the Modern Web

#30

Post by tashoecraft »

rich_harris wrote: post #14
grey-area wrote: post #3

This author seems to think the only competitor to react is other js frameworks, when in fact most of the web's largest sites work just fine with small amounts of what he calls 'artisanal js'. You probably don't need your js framework, your 10k npm dependencies, or your complex mix of server and client side rendering. Not every website needs an api and clients to consume it, and not everything needs to be an app. The…

> your 10k npm dependencies Believe me, you're preaching to the choir. Nor am I advocating for every website to have an API. But unfortunately we part ways here: > The web is a success The web is not a success. It's dying. Consumers vastly prefer native apps — one recent study ( https://www.mobiloud.com/blog/mobile-apps-vs-the-mobile-web/ ) tells us that 90% of mobile time is spent in apps vs 10% in browsers.

Apps only work for very specific use cases. The difficulty in getting people to download your app shows that. That study doesn’t seem to break down what apps are being used. I’m going to guess games, as they dominate the charts, or specific websites that have created mobile apps. Facebook, Twitter or maps, which are used for multiple hours straight when driving.

If there is a site you use often enough it graduates to living in your phone. But the majority of what apps can do is never even touched.

I’d be much more interested in a breakdown of app usage, as I bet active time shifts more towards web

Post reply on HN