Live data from Hacker News

In Defense of the Modern Web

dev.to

91–100 of 224 posts

Re: In Defense of the Modern Web

#91

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.

There was/is so much that was genuinely awesome about jQuery. I still remember fiddling around with my blog as a teenager and being blown away by the DataTables plugin.

Re: In Defense of the Modern Web

#92

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.

I agree, and moreover I find the native app animated transitions held up as the end-goal to be nothing short of awful.

Re: In Defense of the Modern Web

#93
post #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.

I think it's more prominent and damaging there on account of all the churn, combined with large amounts of stupid money.

Mobile native developer? Might be something new you want to get familiar with every couple years, but really you'll likely be OK, career-wise, if you sleep on it for another year or two unless you actually need it. C++ developers aren't chasing brand-new frameworks to stay hirable, generally. Java and C#, most of the ads seem to be "have experience with [eight-year-old 'new' thing that's basically an ecosystem-wide standard now anyway], plus a bunch of much older things", and those two alone are a really high percentage of all software jobs.

Re: In Defense of the Modern Web

#94

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.

It depends. Neat short animations can be nice. Even your lightbulb “dimming in” and out would be quite nice.

What you’re complaining about is the lightbulb taking 3 seconds to turn off and its toggle costing $100. Now that something nobody likes.

Re: In Defense of the Modern Web

#95

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.

Web apps are dying because the web isn't a good application platform. Google made a real good argument with Gmail and Maps, but unless you have their resources (even if you do, looking at Facebook here), it's very hard to create a great application experience on the web--for many of the reasons you write about in your post.

But I think that's fine. The web isn't a good application platform, but it is a good information platform. There's also other protocols beyond HTTP. Imagine if getting the most out of the internet didn't require millions of lines of C++, hyper-complicated JS JITs, layer upon layer on HTTP, and opening the door to the surveillance state.

Re: In Defense of the Modern Web

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

Hey that Makepad looks great. Too bad it doesn’t make my phone keyboard appear. You know… the same thing you get by adding a plain `contentEditable` DOM attribute. Maybe reinventing the whole damn car on canvas isn’t a great idea either. I bet that the keyboard isn’t the only part that doesn’t work. Flash was hated for this reason too: Breaking affordances. Imagine everyone reinventing their own UI framework on each…

> Too bad it doesn’t make my phone keyboard appear.

I don't like this argument. It's like saying that because C++ can do everything, we don't need to build a new language to fix problems inherent with the existing paradigm.

Rust is just getting started, so give it time.

DOM is overloaded, messy, and slow. We need an application UI toolkit similar to what Android and iOS provide.

Re: In Defense of the Modern Web

#97
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?

Did I miss something and the many people who are willing to defend React suddenly disappeared?

Re: In Defense of the Modern Web

#98
post #59

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…

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

Ah - I didn't have anything quite that powerful in mind, more like fairly simple, browser-local enhancements to make interacting with regular old HTML pages more pleasant. For example a drop-in library that would save the state of a form and restore it on a refresh, like the old formsaver jQuery plugin. I would like to see an ecosystem of libraries like that again

Re: In Defense of the Modern Web

#99
post #95

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. Web apps are dying because the web isn't a good application platform. Google made a real good argument with Gmail and Maps, but unless you have their resources (even if you do, looking at Facebook here), it's very hard to create a great application experience on the web--for many of the reasons you write about in your post. But I think that's fine. The web isn't a good applicat…

Even gmail and Google Maps aren’t what they used to be. On a machine that isn’t top of the line, Gmail takes ten+ seconds to load to interactivity, and then going to each email takes five or so seconds. It’s basically unusable.

Re: In Defense of the Modern Web

#100

Earlier quoted context omitted.

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?

Because ios refused to allow web pages to have the same functionality as javascript within a mobile app?

And for good reason; I don’t want individual web pages having access to everything that an app can do.
Post reply on HN