Happy to admit it's a crazy idea, and it's not something that I would want to see as a usual way to built sites. But for small areas of web apps where compatibility is difficult it does make sense.
Google Docs used to be contenteditable based, but moved to a custom rendering engine. They are a large enough company to be able to invest in that. Small businesses aren't, and have to rely on content editable.
Ladybird as a contenteditable polyfill would help smaller teams, or single developers, achieve the same, while also building on the existing tooling and APIs for contenteditable.
Isn't this actually prove that creating desktop grate applications, like a graphical word processor form the late 90's & some colab backend, is still infeasible with web tech?
Doesn't it also prove that it's still easier and faster to create a proper app and GUI toolkit yourself and just render pixels to the screen (as all desktop GUI toolkits do these days) instead of fighting the browser tech idiosyncrasies, even a proper app and GUI stack isn't trivial in itself?
> Doesn't it also prove that it's still easier and faster to create a proper app and GUI toolkit yourself and just render pixels to the screen (as all desktop GUI toolkits do these days) instead of fighting the browser tech idiosyncrasies, even a proper app and GUI stack isn't trivial in itself?
jmo, but i think so as well....
tho i wonder what the performance/battery-life implications of everything doing that might be... perhaps you could have an 'libhtml' for static sites and documents, and different ones for more interactive apps etc
Maybe not exactly the same. But whatever could have been improved on that base in the last 15 years.
The point is: We had much saner tech. Now it's just complete craziness, and still you can't even build a word processor like the one that run on Windows 95. This says just everything about the state of web tech for application development. (And no, this tech is rotten from the roots, so you can't improve on it. It'll get only more crazy and shitty if you try further.)
As an industry we’ve taken a long and windy path to delivering full applications (with a local cache) on every load to a sandboxed environment that is mostly compatible across environments.
While it’s easy to take shots at the current state, I find it hard to imagine another path to delivering a cross platform application over the network. What we have now is actually pretty rad.
We built it stone by stone, incrementally, and now I don’t have to package my application for N platforms unless I want to meet users in their app stores.
If we spent all the effort we used up on making JavaScript work on Java instead, I’d be typing this from my Moon habitat.
But we instead chose a pig, buried it under layers of lipstick, and strapped a jet engine onto it. Sure, it’s airworthy, but was it the best way to allocate resources?
I wouldn't say we chose a pig and buried it under layers of lipstick. I think it's more accurate to say people realized:
1) You could deliver software via a browser with some clever hacking
2) That delivering software via a browser had some extremely attractive properties compared to other approaches
Those clever hacks turned into real applications and those became real products. As people built applications on top of browsers, the browsers evolved to be a better environment for building applications. It was very organic.
The actual language we ended up using is just a byproduct IMO. I don't think people chose JavaScript, they chose the browser and the browser had JavaScript. And since the browser had JavaScript, we kept pushing the limits of JavaScript because we needed to deliver applications to the browser.
Honestly hard to see this happening efficiently in any other way. All things considered, the web platform is pretty fantastic compared to the software distribution story in every other ecosystem. I'd argue that we allocated resources pretty well on this one!
I didn't miss them - I don't have fond memories of them as either a user or a developer. But you're right, they were there. Which is interesting: Java Applets were available from close to day one right along side JavaScript, and yet...
There are two use cases for the web. There is the document web and the application web. Both are equally valid. It is absolutely an application platform, as evidence by the fact people use it to deliver applications. An ever increasing percentage of desktop software is moving to the browser, to the point where many users only need a web browser. I'd argue the only reason mobile hasn't followed suite is the non-market forces behind the app store model.
It is one of the best application platforms for both users and developers. I can write my software exactly one time and it will run on every platform, instead of separate applications for Android, iOS, Mac, Windows, FreeBSD, Linux, etc. etc.
I can assume my users have a web browser - because they do. For interpreted languages (and VMs) I either have to walk my users through setting up the interpreter or bundle it into the distributable.
Compared to everything else I've worked with, the web as an application delivery platform is great. I write my code, send someone a link, and they are running my app.
> Java Applets were available from close to day one right along side JavaScript, and yet...
And yet, what?
But the actual question is: Why? ;-)
> There is the document web and the application web. Both are equally valid.
No, they aren't. The tech was build to support only a lightweight version of the first one. Everything on top is just a great hack, and pure insanity form the technical viewpoint!
> It is absolutely an application platform, as evidence by the fact people use it to deliver applications.
People do a lot of very stupid things. That's not evidence that doing stupid things is a good idea…
> An ever increasing percentage of desktop software is moving to the browser
Nobody is doing that because web-tech is a great application platform. It's actually exactly the other way around: Most people complain about the extremely crappy tech, but still do it for other reasons.
> I'd argue the only reason mobile hasn't followed suite is the non-market forces behind the app store model.
This makes no sense.
It would be much cheaper for the developers to not pay road toll to the app-store owners (-30%!), and they would at the same time remain in control over their own products, if they "delivered" web-apps. But most mobile developers don't do that, for technical reasons: Web apps are just crap and especially on mobile it glaringly shows.
> I can write my software exactly one time and it will run on every platform
You mean, like JVM applications already did 25 years ago?
> Compared to everything else I've worked with, the web as an application delivery platform is great. I write my code, send someone a link, and they are running my app.
What's again the difference here to Java WebStart?
BTW: Installing a JRE is exactly the same one-off effort like installing a web-browser…
---
We lost between 20 and 30 years once again just for political reasons!
Only to arrive at the worst rip-off of some concepts which were already almost "working fine".
I admit that's a recurring pattern. It's always the most terrible tech that will come out on top in the end, for completely insane "reasons". The market just always favors the cheapest shit that can be rolled out with least effort. It was like that for example with things like C or UNIX. Now "worse is better" became a kind of proverb in some circles…
To be of the opinion that the technical best solutions win in the market is imho a sign of not much experience in this world. It was until now the exact opposite in almost all relevant cases, because most of the time the cheapest shit wins on the market.
