6 ms·
I'd argue that the problem isn't so much backward compatibility than being opinionated vs not. Qt knows what it's doing, knows what it isn't doing and then from
by simias 7y ago
I'd argue that the problem isn't so much backward compatibility than being opinionated vs not. Qt knows what it's doing, knows what it isn't doing and then from there defines the perimeter of its APIs.
For better or worse the web never did that work, HTML+CSS+JS is meant to be both a way to make static websites, but also interactive e-shops, but also mail clients, but also videogames, but also ultra-heavy single-page apps like Discord etc...
And that's the greatest power of the web, but I can't see how this state of affair won't lead, one way or the other, towards a more monolithic architecture. Keeping HTML and CSS cleanly separated and JS only for the fancy stuff (but always optional!) is noble but it's a pipe dream when the use cases are so diverse. WebAssembly, or something like it, seems to be clearly the path forward.
Overall I think we should be happy too, at least it's not a closed source blob. Remember how long it took us to get rid of bloody Flash? Actually if Steve Jobs hadn't decided to drop it from iPhones I wouldn't be surprised if it had survived in common use to this day.
- joshuarubin 7y agoIt's hard to identify specific decisions made by Jobs from the outside, but killing Flash on the iPhone seems like something _only_ Jobs could have done. Sure he and Adobe were in a tiff... Anyway, it's likely that this is a rare case where one person making a unilateral, perhaps tyrannical, decision benefited the whole world.
- BlueTemplar 7y agoThe fancy stuff can go live in apps, it has nothing to do in a browser designed for webpages first. I mean, just compare the GUIs of VLC and YouTube!
- shadowgovt 7y agoBut with the strong advantages of access to the Internet that a website brings (which is itself a whole bag of hard problems to solve), the appeal of building things accessible via browser user-agent (regardless of what the thing is) is huge. It shouldn't be necessary to toss out the cookie jar, the HTTP connection handler, the XSS protection just because one wants to do something a bit different with the final rendering stage.
- BlueTemplar 7y agoWhat prevents access to the Internet from a non-website ? Why use the HyperTEXT Transfer Protocol for things completely unrelated to text - it's not like other, more appropriate protocols are not available, or cannot be designed ! (Or that URLs are limited to HTTP...)
- Pete_D 7y agoPartly firewalls and proxies. If you've not read it already you might be interested in https://tools.ietf.org/rfc/rfc3205.txt https://tools.ietf.org/rfc/rfc3205.txt ("On the use of HTTP as a Substrate"). I wish we still built protocols too.
- BlueTemplar 7y agoIndeed. IMHO the right move would be to put pressure on bad actors that only allow HTTP over port 80 and still claim to be "ISPs"... (And with IPv6 having been finalized, NATs are now obsolete.) And, as they say : > It would be useful to establish guidelines for "firewall-friendly" protocols, to make it easier for existing firewalls to be compatible with new protocols. I believe that the Internet is fundamentally about protocols, and that platforms are to be banned if we care about it : https://knightcolumbia.org/content/protocols-not-platforms-a-technological-approach-to-free-speech https://knightcolumbia.org/content/protocols-not-platforms-a...
- shadowgovt 7y agoNovel protocols have their uses, and when that use can be demonstrated they can find their niche. But their value has to be extremely high to justify the opportunity cost of using them over something more established. To turn the question sideways a bit, there's nothing stopping some conglomeration from developing an alternative to 802.11 standards. All they have to do is create the hardware, convince people to use the hardware, create software to adapt a novel protocol to the higher layers of the networking stack to make it usable by application software (including addressing all of the ways that a new lower layer inevitably breaks an abstraction or two), and create the tooling necessary to make an ecosystem of non-802.11 wireless devices easy to install, maintain, and interoperate. ... But outside of particular special applications where something about 802.11 protocols or the frequencies they communicate upon makes them an ill-fit, there aren't many reasons to do so. Good enough displaces perfect in the common case.