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

151–160 of 224 posts

Re: In Defense of the Modern Web

#151

Post by Izkata »

gambler wrote: post #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 th…

> Preloading hovered links can be done with a standalone library.

Couldn't it even be done in two lines with vanilla javascript? On hover fetch() the URL, then rely on the browser cache for when the user actually clicks?

Re: In Defense of the Modern Web

#152

Post by Spivak »

perilunar wrote: post #116
naavis wrote: post #66

Earlier quoted context omitted.

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 are: * platform agnostic * can't be blocked by a central platform gate-keeper * generally much smaller (download size) than native apps * don't take up permanent space on your device (good for things you only use occasionally) * always up-to-date Personally I prefer native apps for tools I use frequently. Everything else I prefer the web.

* The trade-off is that they're alien to the platform either behave entirely different or at worst poorly emulate platform semantics.

* this is true-ish. It's not that they can't it's that they aren't. If Apple or Google just up and blocked a site in Safari or Chrome it's basically dead. "Technically accessible in Firefox" isn't exactly a selling point. You're also gate-kept by your ability to get a public cert.

* True but download size only really matters on first install. It's absolutely friction but not really something that I've ever seen people care about anymore. Pictures take up almost all of the storage on people's phones now.

* True but the trade-off there is that you have to download it every time. Native apps win in the long run if you use it often.

* Users have never cared about this. This is only a benefit to the very techy.

Re: In Defense of the Modern Web

#153

Post by the_gastropod »

rich_harris wrote: post #135
the_gastropod wrote: post #111

Earlier quoted context omitted.

Yes, this. I about fell out of my chair reading this paragraph. In these discussions, I find defendants of these SPA designs to almost always point to vague points about "rich UI" or "highly interactive", or make up complete hypotheticals like this example of pre-loading likely-to-be-clicked links. Show me the code. Show me the crazy-fast link-click-predicting website that does this and loads faster than, say, Hacker…

> Show me the crazy-fast link-click-predicting website that does this and loads faster than, say, HackerNews. https://hn.svelte.dev/ is a Sapper implementation of Hacker News. It uses the preload-on-hover/touch technique described in the article. In my experience it does indeed feel faster than Hacker News, despite basically being something I threw together one weekend

Credit where credit is due: this is excellent work! Very impressed.

Re: In Defense of the Modern Web

#154

Post by Spivak »

Izkata wrote: post #151
gambler wrote: post #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 th…

> Preloading hovered links can be done with a standalone library. Couldn't it even be done in two lines with vanilla javascript? On hover fetch() the URL, then rely on the browser cache for when the user actually clicks?

And isn't this what browsers do already with prefetch?

Re: In Defense of the Modern Web

#155

Post by gbear605 »

reaperducer wrote: post #119
gbear605 wrote: post #99

Earlier quoted context omitted.

Even gmail and Google Maps aren’t what they used to be. On a machine that isn’t top of the line, Gmail takes ten+ seconds to load to interactivity, and then going to each email takes five or so seconds. It’s basically unusable.

On a machine that isn’t top of the line, Gmail takes ten+ seconds to load to interactivity, and then going to each email takes five or so seconds For giggles, I just loaded HN on a 2011 MacBook Air. It took just under 2 seconds for the front page. Then I loaded GMail on the same machine. 15 seconds to the front page. Plus, it came in with 21 errors ranging from invalid headers to invalid sources to cross-origin issue…

The errors are really embarrassing. Come on Google, how hard is it to just not have cross-origin issues?

Re: In Defense of the Modern Web

#157

Post by pier25 »

robertoandred wrote: post #137
pier25 wrote: post #115

Earlier quoted context omitted.

> your 10k npm dependencies Svelte projects do not put 10k dependencies in the final bundle. In fact when using Svelte you won't need many dependencies you typically need when using React: - State management (MobX, Redux, etc) - CSS stuff (classnames, CSS in JS, etc) - Animation Even on a simple use case like a synthetic benchmark Svelte is still the absolute leader in start-up metrics: https://krausest.github.io/js-…

You don't need additional state management or css "stuff" to use React.

Certainly but it's very common.

Re: In Defense of the Modern Web

#158

Post by juped »

snazz wrote: post #69
filleduchaos wrote: post #42

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…

LiveView may not be "the future", everyone loves their Javascript too much, but it is the future for me. AJAX with the server is what I feel I was promised back in the Web 2.0 days, not tons of Javascript running in the browser.

Re: In Defense of the Modern Web

#159

Post by juped »

gbear605 wrote: post #99
camgunz wrote: post #95

Earlier quoted context omitted.

> The web is not a success. It's dying. Web apps are dying because the web isn't a good application platform. Google made a real good argument with Gmail and Maps, but unless you have their resources (even if you do, looking at Facebook here), it's very hard to create a great application experience on the web--for many of the reasons you write about in your post. But I think that's fine. The web isn't a good applicat…

Even gmail and Google Maps aren’t what they used to be. On a machine that isn’t top of the line, Gmail takes ten+ seconds to load to interactivity, and then going to each email takes five or so seconds. It’s basically unusable.

There's no good reason for an email client to be a SPA rather than normal web pages with some scripting to get pushed relevant updates.

Re: In Defense of the Modern Web

#160

Post by combatentropy »

I wonder if a lot of the disagreement is just people talking past each other.

I used to think it was an oversimplification to divide the web into Documents and Applications. I thought it was more accurate to say it was a continuum, and using two different techniques was a sign that we still had not figured it out. After all, a blog post about programming might have an interactive example. An article about retirement might embed a calculator. If you try to categorize a site or even just a page as Document or Application, it gets fuzzy. But if you look at a page and just try to categorize it section by section, as Document or Application, it's easier. (Hence, Web Components make more sense to me.)

So anyway, most people spend some time surfing the web --- by that I mean visiting Documents. Clicking links from search results, to articles, to more articles. If you aren't using an adblocker, I can't imagine how you don't end up throwing your laptop against the wall. I ended up just turning off JavaScript for most sites, and the web looks more like how I think it should look. Every once in a while these people will post a rant, and it will resonate with most people.

But then an Application Developer will read it after a long day and say, hey, wait are you saying I should write my Application (like GMail) in jQuery? To be honest, Applications don't bother me the way overscripted Documents do. I almost expect them to be kind of slow. After all, even some Desktop Applications still have loading screens. So I don't mind so much if you're using React or whatever for your Application or even for that calculator embedded in the article about savings.

But for Documents --- like articles, blog posts, company home pages --- well, one thing I agree with SPA developers is that there could be less server-side rendering. These kinds of sites could often be compiled ahead of time into static HTML. Server-side rendering is better than SPA for these kinds of sites, but static sites are better than server side. I mean, who enjoys getting "Error connecting to MySQL database"? (Okay, that's rare.) I'm intrigued by the old-new JAM Stack :)

Post reply on HN