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

51–60 of 224 posts

Re: In Defense of the Modern Web

#51

Post by nathcd »

tashoecraft wrote: post #25
rich_harris wrote: post #8

Earlier quoted context omitted.

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.

Agreed, I’ve often opened another tab, found the context of the comment I’m replying to and hopped back and forth. HN can be an echo chamber of JavaScript is the devil, websites should only serve html.

> HN can be an echo chamber of JavaScript is the devil, websites should only serve html.

It's a reaction to the reality of the web, which is that Javascript is commonly used when it's entirely unnecessary, much more of it is often used than is necessary, and it's often used to abuse webpage visitors. Most on HN don't object to ajax-y bits of JS that make a page more pleasant to use.

Re: In Defense of the Modern Web

#52

Post by Dacod »

amw-zero wrote: post #33
tashoecraft wrote: post #30

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?

Downloading apps is not difficult but it's difficult to get people to download apps.

Re: In Defense of the Modern Web

#53

Post by jessaustin »

echelon wrote: 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…

The author isn't just a React apologist...

Nothing about TFA indicates that its author is a React apologist. Do those even exist anymore?

Re: In Defense of the Modern Web

#54

Post by quantummkv »

frosted-flakes wrote: post #49
quantummkv wrote: post #22

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

But what if the user does not click on it but clicks on something else? Then we are back to square one with a lot of effort for nothing.

> I believe Gatsby will pre-load any link that's visible in the viewport by default$

If it does that, then no wonder that the original article was completely right. On a page with 10 visible links in the viewport, I will only navigate to one or maybe I won't navigate. Then why the hell is my battery, network bandwidth, etc is being used for it what is essentially 90% wastage?

Re: In Defense of the Modern Web

#55

Post by fenwick67 »

amw-zero wrote: post #19
fenwick67 wrote: post #4

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…

I don't really have a problem with web apps doing incremental loading when it makes sense (Facebook, for example, or letting the user add a comment in situ), but many many sites would be better off just loading documents instead of moving to an application framework. Take for instance TechCrunch.com vs Wired.com, Wired is much easier to use because it acts like a website. Yes, it does full page refreshes instead of showing a full-page loading spinner, but it behaves more consistently and doesn't require the user to learn new UI paradigms.

Re: In Defense of the Modern Web

#56

Post by krapp »

ecmascript wrote: post #12

Interesting take and I kind of agree. My take is, however, that the web as we know it is going to be split in apps and websites. Sites is stuff that works fine with an 'old classy' request->response method, stuff like blogs, newssites, wikis, information sites, simple booking sites etc. You can make a great living just doing that. Probably most content available on the web will fit in this category. However I think W…

I think it's more likely that "applications" will tend to be be compiled directly to WASM and served over the web that way.

Re: In Defense of the Modern Web

#58

Post by grey-area »

speedgoose wrote: post #27
timw4mail wrote: post #24

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.

But you don't need javascript frameworks to add a small amount of state changes without page reloads, it's very easy to do without using something like react.

The comparison is between server-side with a bit of js where required, and the proposed 'modern web' where js frameworks attempt to take over the entire experience server and client side so that they can remodel the world in their image.

Most websites simply don't need react and friends, even if they are more app-like than doc-based they still don't need it, and they certainly don't need to be a single page application (the best modern example of throwing out almost everything that is good about the web - urls, links, docs, stateless).

Re: In Defense of the Modern Web

#59

Post by basch »

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…

Right?

Are you thinking something like ShareDB? https://github.com/share/sharedb

As a person who is browsing the web, I do want server rendered pages, correct history of navigation, urls to match pages, a lack of refreshes, live collaboration with other users. What I dont want is a manual refresh to lose anything or bring me to a different page. And I want the site to work, and progressively fail if I have javascript off.

Most interactivity can still be server side. Look at google.com, as you type in a search query, and they return a static update with results matching what youve typed so far.

Re: In Defense of the Modern Web

#60

Post by quantummkv »

rich_harris wrote: post #36
zozbot234 wrote: post #23

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.

> You could recreate the open-the-reply-page-in-a-new-tab behaviour of HN

That is the crux of the problem. Why is there this obsessive need to recreate what is already available?

> with a few kilobytes of JS if you're doing it right.

As experienced with PHP developers in the dark ages, that never works. It will be a choice between easy and incorrect or difficult and right. The majority will never do it right for various reasons. And the web will loose in the eyes of the users.

Post reply on HN