There is a ton of unbelievably bad web code out there. jQuery is a great example of a 'huge' and popular slowdown for a minor gain.

Sure, it's 'worth it' because nobody cares if a web app takes 1/2 second to render, but as soon as you trade speed for anything else you quickly end up with code that's as slow as your willing to live with.

Having said that there are a few modern web-apps that really got 10x faster while sticking with HTML, CSS, and java-script so it's possible. The trick is stick with competent people and reasonable designs.

I believe it's been discussed many times before. Developers who use jQuery do so because it provides a good API / abstraction layer, as dealing with browser specific issues could be non-trivial.

> The reason for that is not 'web developers' but rather the fact that a single delivery device for a huge variety of content without intermediaries is a thing no corporation will be able to ignore.

That argument doesn't work because that was already possible with TCP, and it doesn't explain the rise of "apps".

The reality is, corporate decision makers saw cheesy demos of web stuff, and said, "Hey, lets use that in production," and instead of saying, "Hey, that's a bad idea let's just use TCP for this application!" the web devs said, "Okay, I guess we can make it work." It's clever and maybe technologically impressive, but that still doesn't make it a great idea, IMO.

> That argument doesn't work because that was already possible with TCP

TCP: low level network protocol, HTTP: high level network protocol, HTML: high level layout description (ok, maybe not that high ;) ).

> and it doesn't explain the rise of "apps".

Actually, you can explain apps (and silos) as a way to undo all that open goodness and to bring control back to the large companies that are (rightly) frightened out of their wits by what an open internet and a peer-to-peer world actually means.

Now if we could get providers to play ball and to allow servers to co-exist with residential services on ports 80 and 25 (somebody think of the spam...) and hand out symmetric bandwidth by default we might be able to undo some of the damage.

Oh goody, so let's go and each roll our own custom brand of query-response and framing over TCP again. That'll be great. And fuck, it's so much faster and more flexible and debuggable to write our tools in window toolkit $whatever than to just use CSS and HTML.

Those who don't learn from history, etc. etc.

There's a reason the web won.

The funny thing is that all of the those problems had been solved and made into libraries for native apps a long, long time ago. And none of them were really solved by moving using the web as a platform.

How do you explain WebSockets and HTTP2?

And instead of creating a GUI in Gtk or Qt, we have IE, Chrome, Firefox, Opera, Amaya, and myriad mobile browsers, all of which behave differently, especially on more advanced JS/CSS/HTML.

The people not learning from history are the web developers. It's pretty clear they're the ones reinventing the wheels...