In Defense of the Modern Web • Hacker News Board

Re: In Defense of the Modern Web

#211

Post by filleduchaos » Sat, May 16, 2020, 12:41 AM UTC

amw-zero wrote: post #209

filleduchaos wrote: post #43

Earlier quoted context omitted.

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

How is that different than any other distribution platform?

I'm not sure it really needs to be explained that if you're trying to introduce a service to someone for the first time, asking them to access a web page (available on whatever device they're with at the moment and up, running and ready to interact with in seconds) is less likely to lose their attention than asking them to download and install yet another app.

Re: In Defense of the Modern Web

#212

Post by cptskippy » Sat, May 16, 2020, 1:08 AM UTC

I'm having a hard time comprehending this mindset.

According to this article we should accept:

- Heavy sites that take a long time to load initially.

- Are sluggish and unresponsive when not on this year's flagship phone.

- Will probably break if the user leaves a tab open for too long.

Because:

- There's an opportunity to shave a fraction of a second off of your page load times if you want to utilize predictive analytics or extensive preloading to ensure the content request is already loaded in cache.

The modern web is just layers upon layers of hacks and it's ugly and slow.

I would recommend to anyone who disagrees to install the NoScript Add-on and run with it for 6 months. I did so and here's some things I've observed...

When I enabled NoScript:

- Most sites do not work without some Javascript that's been used to address Page reflow. They have a global display:none attribute that's removed after the entire page has loaded. All this discussion about page load times or responsiveness is BS when sites are hiding their site from you until it completely loads to avoid reflow.

- Most sites rely heavily on Javascript to do basic formatting that's trivial in CSS.

- Most sites use Webfonts loaded via Javascript

When I disabled NoScript:

- My Phone went from 60% battery at the end of the day to - The Web is slow again.

- User hostile behavior like pop overs, auto-play video, and other garbage.

Re: In Defense of the Modern Web

#213

Post by rich_harris » Sat, May 16, 2020, 1:51 AM UTC

cptskippy wrote: post #212

I'm having a hard time comprehending this mindset. According to this article we should accept: - Heavy sites that take a long time to load initially. - Are sluggish and unresponsive when not on this year's flagship phone. - Will probably break if the user leaves a tab open for too long. Because: - There's an opportunity to shave a fraction of a second off of your page load times if you want to utilize predictive anal…

> According to this article we should accept

Well, I wrote the article, so I can say with some authority that you've badly misinterpreted it! Somehow I manage to build sites with exceptional performance that are snappier than the equivalent JS-free sites, using the techniques I talk about (and https://svelte.dev).

Yes, there are a lot of bad sites out there that abuse JavaScript. No, that doesn't invalidate the article's thesis; it supports it.

Re: In Defense of the Modern Web

#214

Post by julianlam » Sat, May 16, 2020, 2:06 AM UTC

rephrase wrote: post #130

Isomorpheus wrote: post #124

Earlier quoted context omitted.

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

Certain, check out https://community.nodebb.org, super quick SPA.

Re: In Defense of the Modern Web

#215

Post by arvinsim » Sat, May 16, 2020, 4:36 AM UTC

kristopolous wrote: post #167

soperj wrote: post #142

Earlier quoted context omitted.

Agreed. Don't know why we're abandoning all the things we get for free with links just to do it all again in a SPA.

Many people doing the coding haven't really thought that deeply about the systems. I'd like "web programming" to start with Vannevar Bush's As We May Think, then go to Licklider, Ted Nelson, then hypercard programming (hypertalk). Set up a BBS, a gopher site and then write HTML for NCSA Mosaic. Read the RFCs and W3C standards, learn about Netscape's SSJS failure before touching nodejs, you know, serious academic scho…

These don't get you a job. I haven't been to interviews that care about these things.

Re: In Defense of the Modern Web

#216

Post by arvinsim » Sat, May 16, 2020, 4:39 AM UTC

ardy42 wrote: post #144

soperj wrote: post #142

Earlier quoted context omitted.

Agreed. Don't know why we're abandoning all the things we get for free with links just to do it all again in a SPA.

> Agreed. Don't know why we're abandoning all the things we get for free with links just to do it all again in a SPA. SPAs are newer, so they must be better, right? /s

The old way of doing things has always worked. Why bother with new technologies and paradigms? /s

Re: In Defense of the Modern Web

#217

Post by bryanrasmussen » Sat, May 16, 2020, 6:41 AM UTC

naavis wrote: post #46

rich_harris wrote: post #14

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

>Does that really mean anything other than you can do more things with mobile devices than just browse the web?

That depends, what is the usage pattern of browsers vs. everything else on the desktop computer? Because you can use the desktop computer for more things than browsing the web.

Re: In Defense of the Modern Web

#218

Post by gunnarmorling » Sat, May 16, 2020, 9:11 AM UTC

zeugmasyllepsis wrote: post #141

gambler wrote: post #68

Earlier quoted context omitted.

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

> .. in favor of targeted JS libraries that extend HTML capabilities. Do you mean libraries like Turbolinks[1] and/or Intercooler[2] here? I'm interested in what libraries you use, and others like these which help "bridge the gap" between traditional and single-page sites. [1] https://github.com/turbolinks/turbolinks [2] https://intercoolerjs.org/

Unpoly [1] is another one in that camp. Made good experiences with to smoothen page transitions in a server-side rendered app [2]. I find this model much more approachable for backend devs than going all-in on SPA. It doesn't help of course with more fine-grained interactions like say in-place editing in a table.

[1] https://unpoly.com/ [2] https://www.morling.dev/blog/quarkus-qute-test-ride/

Re: In Defense of the Modern Web

#219

Post by danjac » Sat, May 16, 2020, 9:56 AM UTC

ss3000 wrote: post #37

rich_harris wrote: post #14

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…

I also wonder how much the current epidemic and increased migration towards WFH will affect native mobile app usage, particularly among non-driving commuters. People will be using desktops more for casual browsing, and thus likely to be using web browsers outside of a small number of desktop apps (office suites, games and so on).

Re: In Defense of the Modern Web

#220

Post by luord » Sat, May 16, 2020, 5:47 PM UTC

Interesting that he agrees with the point of the original article I disagree with the most, the one on APIs. Maybe I'm wrong...

Speaking of which...

> I'm not aware of any other platform where you're expected to write the logic for your initial render using a different set of technologies than the logic for subsequent interactions.

I'm not aware of the backend, the server side of many mobile application being written in kotlin (or java) or swift.

In fact, it's common for the server and the client to be written in different technologies.

Yes, I know that's not exactly what he means and in a native application, the application is in charge of the initial render. But he's criticizing APIs and I don't see how this statement can be possible without APIs unless he expects the backend to be in the same technology. Which, again, is not unusual for it not to be so.