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

201–210 of 224 posts

Re: In Defense of the Modern Web

#201

Post by ric2b »

Wowfunhappy wrote: post #122

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

That's probably because those animations are made with JS in the main thread, so the whole thing becomes unresponsive while they happen.

Re: In Defense of the Modern Web

#202

Post by rado »

amw-zero wrote: post #32
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.

Well, I think this is really hyperbolic. I think it depends on the application, and the consumer. And the web is a tremendous success. You should take a step back and look at how your entire life is affected by the web. It seems really, really off the mark to say that the web is not a success. You can criticize it, sure. But - you are using a computer 100% because of the web, not because of spreadsheet software. Now,…

FB's 5" of page load is a miserable failure that makes me question what I am doing here.

Re: In Defense of the Modern Web

#203

Post by pier25 »

filleduchaos wrote: post #176
pier25 wrote: post #112

Earlier quoted context omitted.

> avoiding full page loads Sure, you can do this with AJAX, but so far there are no SSR + component-level hydration + AJAX frameworks that solve this out of the box. Facebook is working on something similar though as Dan Abramov has hinted at on Twitter.

Why, exactly, does a static site need component-level hydration?

If it's a totally static site it certainly doesn't need it.

But if you have any amount of interactivity (forms, widgets, etc) SSR makes total sense. Specially with component-level hydration which means the duplication of content would be lower than traditional SSR. AFAIK Marko is the only framework that has this feature.

See this article for more info on this topic:

https://medium.com/@mlrawlings/maybe-you-dont-need-that-spa-...

Re: In Defense of the Modern Web

#204

Post by gambler »

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/

Yes, those are some of the examples. You can roll your own as well. With modern JS and CSS selectors you can create useful, reusable libraries with just several dozen lines of straightforward code.

Re: In Defense of the Modern Web

#205

Post by giantrobot »

ss3000 wrote: post #21
timw4mail wrote: post #7

Earlier quoted context omitted.

If it works without JS enabled that way, but works the current way with JavaScript, what's the problem?

As far as I'm concerned, the problem is the people who choose to disable JavaScript and demand to be catered to without considering how much extra development resources I'd have to allocate to maintain a version of my app that works with JavaScript disabled, despite barely even constituting a rounding error in my usage statistics, and the JavaScript version offering a vastly superior experience for the rest of my use…

Everyone has JavaScript disabled sometimes. https://kryogenix.org/code/browser/everyonehasjs.html

Re: In Defense of the Modern Web

#206

Post by giantrobot »

tenaciousDaniel wrote: post #20
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'd really love to see an entirely new rendering context for the web. Right now you have to go WASM > JS > DOM. What if there was something else, like AOM (application object model) that gave direct access to WASM. It would allow the DOM to go back to what it was originally intended for - interactive documents.

``

Re: In Defense of the Modern Web

#207

Post by tenaciousDaniel »

giantrobot wrote: post #206
tenaciousDaniel wrote: post #20

Earlier quoted context omitted.

I'd really love to see an entirely new rendering context for the web. Right now you have to go WASM > JS > DOM. What if there was something else, like AOM (application object model) that gave direct access to WASM. It would allow the DOM to go back to what it was originally intended for - interactive documents.

` `

eh, not really. It's true that Canvas is its own rendering context, but it's just a drawing API. There is a whole suite of technology needed for applications that is currently only available to html/js. Things like accessibility, text input, etc. What I'm imagining is a rendering context that, like the html document, provides those things out of the box.

Re: In Defense of the Modern Web

#208

Post by amw-zero »

fleddr wrote: post #195
amw-zero wrote: post #19

Earlier quoted context omitted.

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…

"Only programmers look at it and say "yea, that's fine," because we know how difficult a web browser is to implement." No, not just programmers. Also end users. It's a complete myth that the traditional link/page refresh method is jarring to users. It's perfectly normal and expected to click a link and to have it loaded in a reasonable time frame, without some weird transition in between.

Not the end users that I talk to and interview. So ‘complete myth’ just means that you have a strong opinion. It doesn’t mean it’s actually true.

Re: In Defense of the Modern Web

#209

Post by amw-zero »

filleduchaos wrote: post #43
amw-zero wrote: post #33

Earlier quoted context omitted.

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

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?

Re: In Defense of the Modern Web

#210

Post by searchableguy »

rich_harris wrote: post #14
grey-area wrote: post #3

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.

I wanted to add one point to that

- most people only install popular apps

- top apps in playstore are actively hostile to using their website.

Reddit, Imgur, instagram, snapchat, whatsapp, twitter etc. You name it. They either don't have a functioning mobile website or native only.

Post reply on HN