Live data from Hacker News

In Defense of the Modern Web

dev.to

71–80 of 224 posts

Re: In Defense of the Modern Web

#71
post #37

Earlier quoted context omitted.

If they dived deeper into the usage patterns and broke down app usage by specific apps, I'd suspect a vast majority of that time is spent in a tiny handful of popular apps, since there are also countless studies pointing to the fact that consumers don't install more than a handful of native apps. If you remove time spent in those popular apps and their respective websites from the stats, the data would likely paint a…

"If you remove some of the data, the data tells a different story"

Or

"It's often useful to take context into account when evaluating statistics"

Re: In Defense of the Modern Web

#72
I needed to read this after fighting with Upwork (an apparently Angular website, which i found out via necessity, trying to figure out if my payment was being processed, double-billed, or not processing at all). Here is another primary example of a victim of the modern web, a website that needs none of it, yet had to be converted to one of the 'constantly spinning wheels on 20MB pages' framework. Thanks, modern web for slowly destroying every service that i use. At this rate, by next year the web will grind to a complete halt.

Re: In Defense of the Modern Web

#73
post #66

Earlier quoted context omitted.

Why do any of those things need to be native apps, rather than instantly-accessible, no-install-required URLs that come with all the protections of the web's security model?

The first thing that comes to mind is that I can use them offline. I don't need the internet to draw or play most games. EDIT: I do understand you can make web apps that work offline by jumping through enough hoops. But then again, why would you? Why try to unnecessarily shoehorn everything into the web paradigm? Let's take an iPad drawing app that is super well integrated with Apple Pencil. What benefit would forcin…

Web apps can also work offline.

Re: In Defense of the Modern Web

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

You can do that without going full SPA. See 'old reddit' vs 'new reddit', with the former being user friendly while remaining minimal and performant.

Re: In Defense of the Modern Web

#75
Genuine question: are smooth page transitions really worth all of this?

It seems that page transitions really are the main reason given for using JavaScript-everything for sites and simple applications that otherwise could have been built with some fast loading HTML and a couple of POST forms.

Re: In Defense of the Modern Web

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

It's going to be interesting change of landscape when we have isomorphic Rust/Wasm delivering truly native web apps that don't render on top of the 30 years of DOM kludge.

Google Sheets has used canvas for rendering for years.

Re: In Defense of the Modern Web

#77
>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. We can provide better visual feedback that loading is taking place and a transition is about to occur. And we don't need to load the entire contents of the page — often, we can make do with a small bit of JSON because we already have the JavaScript for the page. This stuff gets fiendishly difficult to do by hand.

No, it's not. It's easy and you can do all that without an SPA framework. If you can't see this in about 5 seconds, you shouldn't be lecturing other about how to design websites.

Preloading hovered links can be done with a standalone library. AJAX can be done with another a standalone library. Removing extra crap from your page to facilitate faster AJAX can be done with a custom request header and a couple if-else statements on the server side. Best of all, this stuff can be added after you have a working website.

Re: In Defense of the Modern Web

#78
post #37

Earlier quoted context omitted.

If they dived deeper into the usage patterns and broke down app usage by specific apps, I'd suspect a vast majority of that time is spent in a tiny handful of popular apps, since there are also countless studies pointing to the fact that consumers don't install more than a handful of native apps. If you remove time spent in those popular apps and their respective websites from the stats, the data would likely paint a…

"If you remove some of the data, the data tells a different story"

Well, "90% of user time on devices is in native apps, 10% web" does paint a rather different picture than "70% of user time is in social media and messaging apps, 10% media apps like Netflix or Spotify, 5% mobile games, 5% all other apps including all the built-in ones other than the browser, 10% web" if you're not in social media, media, or games and trying to decide whether to go web or native.

Re: In Defense of the Modern Web

#79
post #69

I was disappointed to find that this post falls into the same pit a number of these defences of the modern web fall into - creating a false dichotomy between "literally no JavaScript whatsoever" and "a framework-authored site with client-side routing". None of the features mentioned in that particular paragraph - user interaction analytics, preloading data and content [on link hover], transitions, avoiding full page…

As discussed on a recent thread ( https://news.ycombinator.com/item?id=23137324 ), there are a variety of nice frontend tricks to make a server-rendered site feel nicer (LiveView, TurboLinks, Livewire, instant.page). I'm a fan of these kinds of solutions. For my 100% static website, https://instant.page does make it feel instant. TurboLinks feels a little "heavier" and has a more complex interaction with other fronte…

Yes - those were the exact technologies I had in mind when reading that paragraph. We've been pre-fetching/loading HTML in place for ages! If all you need is faster/less jarring transitions between static pages, it's incredible to me that anyone would immediately reach for an SPA.

Re: In Defense of the Modern Web

#80
post #37

Earlier quoted context omitted.

If they dived deeper into the usage patterns and broke down app usage by specific apps, I'd suspect a vast majority of that time is spent in a tiny handful of popular apps, since there are also countless studies pointing to the fact that consumers don't install more than a handful of native apps. If you remove time spent in those popular apps and their respective websites from the stats, the data would likely paint a…

"If you remove some of the data, the data tells a different story"

If some of the data are outliers, they arguably should be removed.
Post reply on HN