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

121–130 of 224 posts

Re: In Defense of the Modern Web

#121

Post by JamesBarney »

rich_harris wrote: post #63
ss3000 wrote: 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"

Based on my and my friend's preferences, we prefer mobile app for apps they will be using a lot and trust, like Facebook/Slack/Twitter/Email, and want to use the web for apps we rarely use or don't trust as much.

Op is arguing that based on our intuition the data aggregated at that level doesn't distinguish between this more complex story and the simple one of "people prefer apps".

Re: In Defense of the Modern Web

#122

Post by Wowfunhappy »

> Web developers are currently trapped in a mindset of discrete pages with jarring transitions — click a link, see the entire page get replaced whether through client-side routing or a page reload — while native app developers are thinking on another level.

In native apps, I'm a sucker for pretty transition animations, and I'd love to see those on the web.

But, every website I've ever seen with those types of fancy transitions for large pieces of content (as opposed to little on-page microinteractions) also feels slow, clunky, and heavy. As such, I've come to associate such transitions with slow, clunky and heavy web pages.

I'm not really a web developer, so feel free to tell me if everything that follows is stupid: It seems unlikely that our "current trajectory" can ever resolve this problem. Instead, we'd need an underlying technological shift in how browsers work.

Most large transitions are basically browser hacks—albeit ones we've used so frequently, and for such a long time, that they've come to be officially supported and accepted. To make them more usable, they'd probably need to work alongside the browser in some manner.

Re: In Defense of the Modern Web

#123

Post by hombre_fatal »

danShumway wrote: post #40
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…

> truly native web apps God forbid. I happen to like adblockers, inspecting app DOM, and applying custom styles and features with browser extensions. I can customize even poorly-built web apps like Youtube and Facebook with enough poking around and custom selectors. It's great. Don't bring native UX sensibilities to the web, or we'll retaliate by pushing Electron even harder for cross-platform native development. And…

> God forbid. I happen to like adblockers, inspecting app DOM, and applying custom styles and features with browser extensions. I can customize even poorly-built web apps like Youtube and Facebook with enough poking around and custom selectors. It's great.

This is weirdly lost on HNers every time this "debate" comes up.

Native apps are the wet dream of any website they complain about for having too many trackers and ads and data exfiltration.

The web browser is a fluke of history that gives users power that we don't have with native apps. Let's not be so quick to give it up just because you've never mitmproxy'd your phone to see what it's doing.

Re: In Defense of the Modern Web

#124

Post by Isomorpheus »

MrRadar wrote: post #83

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

> Maybe that's just confirmation bias and I just don't notice it as much on sites that do it well

This seems to me to be the key phrase.

I sympathize with all the "JS has gone too far" people in this thread. I also hate bloated JS apps. But, "almost all SPAs are bloated trash" is a distinct claim from "SPAs are intrinsically trash".

In my experience it is possible to have lean, high-performance, accessible SPAs without too much developer difficulty. Svelte (created by the author of this article) is one framework in this space, although I think there are better approaches.

Re: In Defense of the Modern Web

#125

Post by rephrase »

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…

I rephrased what you were saying to take out the negative valence.

This is similar to other articles I've seen that draw a distinction between two choices: zero javascript vs full SPA. I think this is a false dichotomoy because most features advertised for SPAs (analytics, data/content preloading, transitions, optimized page loading) can be implemented for static sites as well. It would be nice to see frameworks that were more modular and interoperable because this would allow/give engineers the choice to decide which parts they want to be static and which parts they want to be dynamic.

I'm not sure if I agree with what you're saying though because you haven't provided examples of how the features of SPAs can be accomplished without JavaScript. Do you have references and examples?

Re: In Defense of the Modern Web

#126

Post by hombre_fatal »

nathcd wrote: post #51
tashoecraft wrote: post #25

Earlier quoted context omitted.

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.

Then instead of an emotional/frustrated reaction, those people should temper their reaction with the acknowledgement of trade-offs.

Re: In Defense of the Modern Web

#127

Post by [deleted] »

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…

[deleted]

Re: In Defense of the Modern Web

#128

Post by hombre_fatal »

zeveb wrote: post #16

All I really want from the web is to get text, images and data and submit form data. I don't really want interactive applications which are almost but not quite entirely unlike proper native apps. I just want to read interesting people and submit my own thoughts in return. I want to see pictures & text about things I want to buy, and submit my address & payment information to buy them. The modern web delivers some of…

You have control over your browser. Just disable Javascript. Some websites don't work? So what?

Now compare that to the rest of software where you don't have that control and you'll see software has always been in the state of your hyperbole about pushing malware to your machine that can always be making http requests that you can't see.

It's a bit sad that even technical people are only waking up to this when it comes to the web because they can finally see it with the browser's network tab, so they think it's just a web problem and begin advocating for throwing the baby out.

Re: In Defense of the Modern Web

#129

Post by Frost1x »

factorialboy wrote: post #57

The criticism isn't directed towards technology X or platform Y. The target is over-engineering. And JavaScript has laid claim to that throne which was once primarily contested by enterprise Java and .Net.

I think it's a combination of both over-engineering and poor engineering leading to unnecessary and unmanageable complexity.

Some project starts and they decide to use an uncessarily complex framework (which may be well engineered for the cases it was developed for at the Facebook/Google scales of the world) then grab 3 more and glue them together using poor practices, then proceed to build all sorts of complexity ontop of that stack using poor engineering and typically non-standard practices.

New people join and voila, they immediately need to understand these 3-4 underlying complex yet well engineered systems and how they are poorly glued together before they can even begin to unravel the poor engineering practices that sit ontop of them so they can fix and extend them.

Parts of the application look well structured, other parts are incredibly confusing. Suddenly you need to go back and better understand some of the underlying frameworks leveraged so you can actually discern what's supposed to be going on which takes forever because that underlying framework is quite complex in and of itself.

In the end you're running around documentation page to documentation page from frameworks and looking at undocumented code someone wrote in between, consuming stupid amounts of time.

Someone built a big pile of technical debt and you just inherited it. Good luck, they've switched to another team, project, or employer and moved on before the mess unfolded.

Meanwhile, you're wondering why 90% of this exists for a product feedback submission form.

Re: In Defense of the Modern Web

#130

Post by rephrase »

Isomorpheus wrote: post #124
MrRadar wrote: post #83

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

> Maybe that's just confirmation bias and I just don't notice it as much on sites that do it well This seems to me to be the key phrase. I sympathize with all the "JS has gone too far" people in this thread. I also hate bloated JS apps. But, "almost all SPAs are bloated trash" is a distinct claim from "SPAs are intrinsically trash". In my experience it is possible to have lean, high-performance, accessible SPAs witho…

Do you know of good SPAs? Sites that feel snappy even though they're SPAs. Most sites I visit that are SPAs are consistently slow so I've learned to make the same association: SPA = bad.
Post reply on HN