So we shouldn't have had Youtube, Vimeo etc. until W3C got around to making <video> part of the official spec in 2010?
The web is great because people kept pushing its limits and weren't arbitrarily held back by bureaucrats. Even though Apple and Google have spent untold billions to push the "there's an app for that" line of thinking, the web has survived.
Your insane perspective and the fact that it is common, is why the internet sucks.
1. Youtube is just a generic video hoster, of which many came before, during, and will come after. As for the whole "pretend Youtube is a thing" thing, I can't remember one actual good video from a "content creator" ever. It's all circle jerking and quick videos on a topic based on least effort.
2. <video> tag has never had a single good implementation. They are all bugged and 100x slower/clunkier than using the built in menu on a CRT TV from the early 90s.
3. Yes, the web would be better if it was just static content. Even without <video> tag. The primary use of a <video> tag is clickbait (actually, almost nobody uses a <video> tag because they don't want to host video, and instead use a youtube embed, so <video> is not even used in practice). For anything else, like movies, porn, etc, it's 1000x more convenient to just download the video and watch it offline in a real video player like MPV. Web browsers still cannot even turn off that stupid "you are now in full screen" banner at the top of the screen, which fortifies my point that <video> is not good for what it is intended for: short one-off clips scattered throughout web pages.
4. The whole idea that it's hard to have a video tag is a product of licesnsing braindamage and the clusterfuck of video encoding standards.
5. The web is not great, and I try to avoid it as much as possible. Using a god damn terminal emulator (the most braindamaged obsolete shit in the world) is 1000x more pleasant than using a web browser.
So write an application multiple times in multiple languages, package it into different packages, and distribute them through app stores? Oh, and desktop Linux users are out of luck because their market share is so tiny, and their distros are so numerous and chaotic that no-one is going to bother spending time and money on building applications for those poor sods. Is this the idea?
How about write an application specifically designed to execute code that you give it in a safe environment. Then you only have to make that application crossplatform and everyone can target it instead. People write for the browser because it is a sandbox, store front, package manager, UI kit all rolled into one. If some smart cookie decides to forget about the web and build to that spec they could come up with a better alternative.
I've thought about this. The thing is that the current relevant browser environments (basically Safari, Chrome, and Firefox) require, what, a billion dollars a year to maintain? 2 billion? And this doesn't even count the various JavaScript frameworks, auth systems, CDNs, etc.
Any replacement technology/protocol which does the same "write once, use everywhere" thing and manages to perform better would still need to achieve wide adoption. And I feel like users would still want that to be able to play seamlessly with everything in their lives that they have online.
It would certainly be a challenge but there are examples of cross platform applications that have succeeded in the market. The Godot game engine is a good one since it does a similar thing for a different segment of the market. It's cross platform and allows you to build applications that target those platforms and more (even the web!). So these things are within the reach of a small team, or even a single dedicated individual. The important thing is to focus on what matters. Providing a safe environment to run code downloaded from strangers, a set of configurable UI elements and an API for making network and storage requests. You're basically building a VM with a UI kit and some networking. You could probably bootstrap up from something simple since it would likely be a fun platform to target for hobbyists, if you could build a community or scene around it.
Which step in that process could not be automated? What's so fucking difficult on either writing a Cross-Platform UI or using a Cross-Platform framework?
<rant>
Is it not instead the case that today's hipster developers simply want to ignore that platforms exist beside their fancy McBooks? Is it not the case that today's developers prefer a bizarre interpreted untyped language simply because that's what they learned for building websites and they don't want to put up the effort to understand what a type system is? Is it not true that the same developers pull in dependencies reflexivly and never consider long-term maintenance, let alone such weird concepts like supply chain security?
And finally did not some hip leaders invent the microservice architecture to cater to these idiots? Because it's nowadays simpler to have a huge, inefficient, pile of services that hides all complexity in the communication between these services than to have one well-designed, efficient system?
</rant>
Sorry for the rant, but sometimes I feel like the industry is actually regressing because many developers are simply lazy morons that hide behind buzzwords.
Please suggest a cross platform framework that doesn't come with accessibility issues, that also allows you to create as rich ui's like what you can do in a browser, and without various licenses that restrict what you can do with your code? Something that supports Android, iOS, Linux, Windows and MacOS.
I feel that it's cheating here to include android and ios in this list, since so much stuff that is developed either:
* is only for those two (and sometimes only one of those) platforms
* the preferred "version" on those platforms in an app, rather than web-based
It's clear from the scope of the mobile app market that there's a huge marketplace for a kind of application that essentially never existed on desktops. It seems a little bold to insist that the same x-platform toolkit must service mobile and desktop contexts, when so much is different between them, in particular display size and interaction style. Even more so when the evidence seems to be that not even the web has really managed to do this.
And yet HTML+CSS+JS which is so hated for making applications handles the use case of working across mobile and desktop almost perfectly. Maybe it's not just because we don't want to learn real programming like the grandparent post insinuated and instead a perfectly viable solution to the problem at hand.
Doesn't fit the part about licenses that restrict what you can do with your code:
"Qt for Application Development is dual-licensed under commercial and open source licenses. The commercial Qt license gives you the full rights to create and distribute software on your own terms without any open source license obligations." https://www.qt.io/licensing/
One of the "open source" licenses that it is under is LGPL, you can do whatever you want with your code. (Although this does not mean that you should, please avoid publishing closed source software)
> What's so fucking difficult on either writing a Cross-Platform UI or using a Cross-Platform framework?
It's been a long time since I used a cross-platform framework so maybe things have gotten better but what used to happen was that I'd run across something in them that didn't work right and then I'd have to do one of:
1. Just not use that in my application,
2. Implement that thing outside the framework which required me to (1) know how to do that thing natively and (2) figure out how to make my implementation work with the rest of the app that was using the framework, or
3. Figure out how to fix the bug in the framework which required me to (1) dive into the framework's internals and (2) probably required me to know how to do the thing natively.
Framework internals are complicated. This complexity is expected--when you are writing a native application you only need the complexity that is inherent in doing whatever it is that application is doing whereas a framework has to be flexible and general enough to serve the needs of a wide variety of applications.
If the framework is going to make me dive into its internals to get it to work there is a good chance that the total effort of making my app run on two or three platforms via the framework will be more than writing separate native apps for those platforms.
Many developers in the industry have simply realized that the flexibility of html/css/js is simply unmatched by any other technology out there. Nothing else out there has been subjected to such extreme levels of scrutiny the web has. Nothing. Afaik, even the Dragon capsules use it for the UI layer.
But since you're such a boi genius, make something that can match and get ahead of it and i'm sure everyone will jump on your boat. Until then, your opinion will remain objectively useless.
Pyramids were also built with a lot of effort. But in the end it was a pile of stones. Architecture was created when labor and material saving technology like the arch was invented. We are in the pyramid phase with the web.
I understand what you are trying to say but you could not have picked a worst example in your analogy. I mean an arch in the end will also be a pile of stones. On top of that we have no idea how the pyramids were made, their precise dimensions and alignment would be extremely hard to replicate using modern technology.
I say we are the arch phase of the web, we understand the arch and it has served us well and it does save a little bit on materials. What we want to do is create bigger and better engineered structures like the pyramids.
Well since you know what phase we're in, and that we're in a phase even, then surely you must know what and when the revolution is. So cut the chatter and get us there. Why waste time?
Jar files are a single file portable to all major platforms (and many minor), that can run offline and have entirely acceptable performance with modern versions and modern hardware (i.e. slower than C but perfectly good if JS in a browser is the comparison). They have inferior security vs browser sandboxing but better no worse than a native binary. Other than being "old", what exactly is the regression?
The webassembly crew is pretty much doing exactly this.
They've worked pretty closely with the folks who designed java bytecode, to try to learn from their institutional knowledge (repeating what they felt they did well, but learning from their perceived mistakes).
It hopefully will end up really nice, because it could provide us with a machine-agnostic IR that will work everywhere, have high performance, and if it becomes popular on the web, I could it leaking into the desktop space and starting to become a standard there as well.
I don’t have much experience with web development, but lately I’ve been wondering, though, if those using browsers as application runtime environments should go all the way and eschew the DOM in favor of presenting a GUI in a WebGL canvas? Theoretically, the combination of WebGL and Webassembly may be an attractive platform for developing cross-platform applications. We already have Electron apps, but instead of using HTML+CSS+JavaScript, we use tools inspired by desktop GUI development tools that render to a WebGL canvas and compile to Webassembly?
That already exists, but it would also mean the end of end-user customizations. As mentioned by sibling poster, accessibility would be nonexistent, but one also could not use adblockers, copy text, etc.
Sure, one /could/ do that. And most web based games do that but then you have to re-invent a whole bunch of stuff. Scrolling, text layout, accessibility hooks, etc.
The web is great because people kept pushing its limits and weren't arbitrarily held back by bureaucrats. Even though Apple and Google have spent untold billions to push the "there's an app for that" line of thinking, the web has survived.