Live data from Hacker News

In Defense of the Modern Web

dev.to

41–50 of 224 posts

Re: In Defense of the Modern Web

#41

Every time a web designer complains that a full-page refresh is "jarring", a bit of me dies. This is like saying a lightbulb turning on quickly is jarring. It's the expected, immediate behavior. If every lightbulb I used turned on with different durations and easing functions or flashed colors at me, or loaded a flashing placeholder while the lightbulb loaded, that would be jarring.

But what you’re describing with lightbulbs is basically an ode to the technical limitations of the time they were invented.

We have had dimmable bulbs that are far less jarring for a long time and now smart bulbs can do the easing automatically when you flip the switch, and change color and brightness depending on time and environment.

It’s such a nice improvement. I don’t even notice until I turn it off and I realize that white light at night is piercing and yellow light during the day makes me sleepy. Or that 100% brightness in the morning and night is way too much.

I think it’s a case of not wanting to go back once you realize what you’ve been missing.

Sure the world you describe with flashing bulbs would be horrible but that’s not what it’s really like.

Re: In Defense of the Modern Web

#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 loads - need a site to be an SPA, nor are they "fiendishly difficult" to do for the [near-]static sites MacWright discusses in his blog post.

I think it's a shame that frontend web developers have thrown themselves behind the SPA paradigm so hard that the notion of a JavaScript ecosystem that doesn't try to do pull _everything_ into its own domain is unimaginable. I'd love to see more mindshare go towards building libraries that are drop-in/"just add water" progressive enhancements for static sites.

[edit: minor grammar correction]

Re: In Defense of the Modern Web

#43

Earlier quoted context omitted.

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…

> The difficulty in getting people to download your app shows that This one I'm always interested in. What is difficult about downloading an app?

You're misreading that statement. Downloading an app is not difficult, _getting_ people to download one is.

Re: In Defense of the Modern Web

#44

Earlier quoted context omitted.

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…

> The difficulty in getting people to download your app shows that This one I'm always interested in. What is difficult about downloading an app?

I personally don’t have much problem with the 100+ apps on my phone, but really it’s an app graveyard. I use maybe 10 regularly. I’ve also cut social media apps from my phone due to battery usage and privacy violations.

Downloading an app is more personal, phone storage space is still a premium for many people. App devs don’t seem to care at all how big there app is. We yell at at web devs when their page is >1mb. I’ve tried downloading simple apps whose size are 400mb, what the hell are they doing? If I can visit their site that’s 1mb or download their app that’s 400x, maybe I’ll just visit the site and be on with my day.

Re: In Defense of the Modern Web

#45

Earlier quoted context omitted.

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

Based on what?

JavaScript downloading and parsing is much more computationally expensive than html parsing.

The DOM seems slow, I think mostly because it requires translating between rendering systems - the representation of the html has to be updated, the styling has to be applied, and the change has to be painted on screen. This explains why updating a documentFragment as a batch operation is much faster than changing the dom directly in a loop.

Re: In Defense of the Modern Web

#46

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.

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

Does that really mean anything other than you can do more things with mobile devices than just browse the web? I might use WhatsApp on my phone, draw with Procreate on my iPad or play games. I don't see why any of those things should involve the web browser, but that doesn't mean the web is somehow dying.

I mean, to draw an analogy, it doesn't mean Netflix is dying if I use 90% of my time at home not watching Netflix.

Re: In Defense of the Modern Web

#47
post #46

Earlier quoted context omitted.

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

> 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. Does that really mean anything other than you can do more things with mobile devices than just browse the web? I might use WhatsApp on my phone, draw with Procreate on my iPad or play games.…

[deleted]

Re: In Defense of the Modern Web

#48

I think one nuance is lost on both articles: web-development is generally stuck in a system where all the incentives are wrong. - The developers want to prove themselves with a new technology - The site owner wants to make money, so adds are required - The website needs to "verify identity" to cut down on fraud, so invasive trackers are added - The finance team wants to cut down on infrastructure costs, so they want…

I think that first item is true about ... a lot of careers. Resume driven development isn't an exclusively web thing.

Re: In Defense of the Modern Web

#49

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

It's hardly crunching analytics. If there's a call-to-action on the homepage, it's likely that the user will click it, so we should pre-load it. I believe Gatsby will pre-load any link that's visible in the viewport by default$

Re: In Defense of the Modern Web

#50

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.

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

That's a very weird assumption to make considering that the web was intended for sharing information, not running applications. The fact that customers prefer native apps does not mean that the web is dead. The web is good for somethings. And native is good for others.

For ex., I read your article on a mobile webpage. Downloading an app for that would be madness. But trying to use a big webapp like jira on the mobile would be a study in madness. Hell, It doesn't work on the desktop well enough.

The bottom line is that the web is good for some things, native apps are good for some things. Instead of trying to shoehorn web everywhere, it would be better to use the correct tool for the job

Post reply on HN