Live data from Hacker News

In Defense of the Modern Web

dev.to

111–120 of 224 posts

Re: In Defense of the Modern Web

#111

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

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

It's good to see the pendulum swinging back to some semblance of sanity on this topic. The past ~5-10 years of the SPA being the default choice has been a wild time. I couldn't be happier that it's starting to receive some widespread criticism.

Re: In Defense of the Modern Web

#112

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…

> avoiding full page loads

Sure, you can do this with AJAX, but so far there are no SSR + component-level hydration + AJAX frameworks that solve this out of the box.

Facebook is working on something similar though as Dan Abramov has hinted at on Twitter.

Re: In Defense of the Modern Web

#113
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"

Wait, are you saying that "90% of mobile time is spent in apps vs 10% in browsers" tells the story that "consumers vastly prefer native apps"? I don't think the connection is that strong.

Taking myself as an example, I may spend 90% of my time on my cell phone using the Messages app, the Phone app and a handful of apps that I installed a long time ago, but I'm much more likely to try out a new web app than I am to try out a new native app. Looking at my phone now, I see exactly one native app that I installed in 2020.

Re: In Defense of the Modern Web

#114

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…

I recently started using Sapper for a personal site and have been enjoying it immensely. I find that the abstractions that Sapper/Svelte make in order to avoid full page loads, preload data, etc allow me to write the site in a component-oriented way while not shipping 5MB of JS to the browser. And, Sapper scales as the app gets bigger in a way that a raw static site just can't.

Rich seems to be advocating for a JS middle-ground here, which I think is a great direction to go in for this kind of workflow.

Re: In Defense of the Modern Web

#115

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

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-framework-benchmark/current.ht...

Also check the metrics for a real world project:

https://medium.com/dailyjs/a-realworld-comparison-of-front-e...

Re: In Defense of the Modern Web

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

Re: In Defense of the Modern Web

#117
post #69

Earlier quoted context omitted.

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.

Funnily enough, the TFA is on a Ruby on Rails blogging platform that uses these tricks to feel incredibly fast. Just look at your network log as you hover links.

Re: In Defense of the Modern Web

#118

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.

> tells us that 90% of mobile time is spent in apps vs 10% in browsers.

Given how hard certain sites (fb, LinkedIn, reddit for a start) push their apps it is kind of understandable.

Please everyone remember though that using does not necessarily mean prefer.

I mostly loathe apps.

Re: In Defense of the Modern Web

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

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

Re: In Defense of the Modern Web

#120
post #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.

IMO the main reason for using React, Vue, or Svelte is not SPA but having sophisticated interactivity with better DX than using jQuery.

A good example are sophisticated forms with realtime validation, dynamic fields that depend on other fields, etc.

Post reply on HN