Earlier quoted context omitted.
> 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.…
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?
In Defense of the Modern Web
221–224 of 224 posts
Re: In Defense of the Modern Web
#222I 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…
Re: In Defense of the Modern Web
#223It’s easier to hire javascript developers, no? Even if it’s not the most efficient.
Being able be assured that you can find/hire folks to work on your tech stack is a pretty important concern for a business. Thus, it can make sense to go with a popular framework/language because it can help in that regard.
Re: In Defense of the Modern Web
#224I'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 arti…
Perhaps but point from Tom MacWright's article is that we're over complicating simple things (e.g blogs) with complicated and heavy libraries and frameworks. Then when we encounter performance issues we attempt to mitigate them by layering on additional crap or spending significant time optimizing the crap out of needless complexity.
Your suggestion that full page loads are unnecessarily slow and cumbersome and that we can use predictive analytics, preloading and a slew of other techniques to get a faster response to a page load is the equivalent of building a Rube Goldberg machine to turn the page of a book "that much faster". Sure your techniques address one metric (i.e. response time) but they introduce all manner of other problems that then need to then be solved. For what?
> Somehow I manage to build sites with exceptional performance that are snappier than the equivalent JS-free sites.
Somehow you manage demonstrate that you completely misunderstood what Tom MacWright was saying. Back to my page turning analogy, I have no doubt someone could build a machine to turn the pages of a book "better" than I can. Does that mean everyone should have this miraculous page turning machine?
At the end of the day my local pizzeria doesn't need a multi-megabyte SPA application utilizing client side ML and predictive analytics for me to get the phone number so I can call in an order, but that's the modern web.