Live data from Hacker News

In Defense of the Modern Web

dev.to

61–70 of 224 posts

Re: In Defense of the Modern Web

#61

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'd love to see more mindshare go towards building libraries that are drop-in/"just add water" progressive enhancements for static sites.

Sounds like jQuery plugins.

Seriously though, I wish for a similar thing without the baggage. Maybe there needs to be a common interface defined for such "just add water" libraries.

Re: In Defense of the Modern Web

#62

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 the most successful document publishing platform in history. It's what enabled this conversation.

Many of the most popular apps are reliant on the web or web servers for their content (social media for example), and it's ok if some content is not on the web. Games for example are a special case which are better served by native code.

A marketer like the one doing those surveys is understandably going to be concerned with where the captive eyeballs are, and platforms do have a tendency to try to herd users into their walled garden, but in the long run I think the open web will win over corporate walled gardens.

Re: In Defense of the Modern Web

#63
post #37

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.

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"

Re: In Defense of the Modern Web

#64

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.

Why do you assume that it's just web designers? Have you ever shown a web app vs. a native app to someone who doesn't write code? Or just someone who has design sensibility? The lightbulb example is also not a good one. A lightbulb transitions between two states. An interactive application transitions between hundreds of states. Full page refreshes make each transition clunky and noticeable. Only programmers look at…

Well, I might be biased as you are saying, and much of this is subjective, but I much prefer a snappy browsing experience, where clicking a link takes no longer than the round-trip time (25-50 ms in most cases) to load the web page.

Have you tried the dillo web browser, for instance? It's refreshingly fast and snappy (including on my old atom netbook from 2008) to use.

I have had a subjective feeling for a while that some user interfaces felt "solid", almost tangible. To me, Windows XP does that. Windows 10 feels like a smokescreen next to it. There might be pretty colors, fancy gradients, but I do not feel like I directly control the UI anymore, I am forced to wait for an animation to finish, I have trouble determining where the window border is. And I've found it much harder to rely on my positional memory to navigate apps that have a smooth transition, like mobile apps.

This is not a rant against Windows10's UI (I have barely used it, and just use it to draw a comparison in the Windows family, you could also compare different KDE versions), but with contemporary user interfaces in general. That could even be said of some command-line interfaces. We're also used to progress bars, or worse: spinners. Trained to wait idle in front of our computers, while a dozen megabytes of frameworks are stuffed down the pipe so that the page background is just the right white shade (probably while I am using a dark theme, and the CSS rules to apply that shade probably only work correctly on Google chrome). That's what modern web feels like to me.

Re: In Defense of the Modern Web

#65
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.…

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?

Re: In Defense of the Modern Web

#66
post #46

Earlier quoted context omitted.

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

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 forcing it onto the web bring, considering the performance hit and usage of specialized hardware?

Or a recording app that I might use to take voice notes or record other audio. Why does that need to be a web application?

Re: In Defense of the Modern Web

#67

Earlier quoted context omitted.

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.

Turn javascript off and find out. The only difference I know of is that the vote buttons force a full refresh instead of making an ajax request.

Re: In Defense of the Modern Web

#68

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…

This.

I've long ago abandoned spaghetti mega-scripts and SPAs in favor of targeted JS libraries that extend HTML capabilities. They're not web components, they don't require some framework to manage, and my HTML works fine without them, but if I load the library and add certain attributes or tags to my markup, I get extra capabilities. The libraries don't require crazy tooling to manage, don't have extensive dependencies and so they facilitate steady incremental development.

I'm very happy with this approach and I'm reusing code I've written years ago for completely different projects.

Re: In Defense of the Modern Web

#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 frontend code, but it works very well.

Re: In Defense of the Modern Web

#70

Earlier quoted context omitted.

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.

> without re-hydrating tens of megabytes of JS for each tab you load You'll be taken more seriously if you don't engage in meaningless hyberbole. You could recreate the open-the-reply-page-in-a-new-tab behaviour of HN (with the context-preserving JS enhancement for the non-middle-clickers) with a few kilobytes of JS if you're doing it right.

It's funny to think about it that way given how much we've pushed back on them over the years, but a pop-up window might actually provide the best experience (bonus points if it was local to the tab).

I just shift-clicked reply, and it works quite well. I might add a rule to my sway config to make the "Add comment" windows floating :)

In the end, everyone is different and has different needs. That's why I like standards: everyone can set their user experience as they prefer it (or pick a web browser that chooses good defaults for them).

Post reply on HN