I would love to see this being adopted and ported as a alternative, light browser for other "esoteric" OSes like Haiku, legacy OS X, and even OpenBSD (which has performance issues with Firefox)
We're building a browser when it's supposed to be impossible
341–349 of 349 posts
Re: We're building a browser when it's supposed to be impossible
#342Earlier quoted context omitted.
I didn't know that. Very interesting! 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 t…
> 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…
> perhaps you could have an 'libhtml' for static sites and documents, and different ones for more interactive apps etc
You mean, like a web-browser from the late 90's + Java WebStart?
Re: We're building a browser when it's supposed to be impossible
#343Earlier quoted context omitted.
I guess you missed Java Applets and Java WebStart… The web browser is still the most terrible "application platform" as it's at its core still a document viewer, and not an application platform at all. The pic with a lot of lipstick analogy is pretty to the spot, imho. You can abuse any Turing-complete environment any way you like. But this doesn't make it a good idea in the first place.
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…
> 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.
Re: We're building a browser when it's supposed to be impossible
#344Earlier quoted context omitted.
Your example is heavily underspecified. In what form are people’s details added? How is the list printed? A spec that’s actually implementable will be a good deal longer. One that defines behaviour completely (what ordering should you use for equal weights?) will be longer still. The HTML and ECMAScript specs that comprise most of what we’re talking about are very much closer to line-by-line, because they’re designed…
If I change my query to be more specific Write a program that keeps track of the name and weight of each person added, sorted by weight, lightest to heaviest. The input should be a command line prompt asking for input in 3 fields - first name, last name, weight. If two people have the same weight, order them alphabetically by last name. At the end, when a blank line is entered, print the list with headings first name…
Still seriously underspecified for an interoperable spec. You haven’t defined the input or output forms anywhere near precisely enough, or how to order alphabetically by last name (sorting depends on locale: e.g. is æ equivalent to ae—though that still raises stability questions—a letter after a, a letter after z, something else? I think there are languages that treat it as each of these. Or are you just rejecting anything beyond ASCII letters, which will cause different trouble?), or what to do about two people with the same weight and last name.
Web specs need to consider all of these sorts of things. That’s why they’re verbose—they’re designed to be implementable and complete.
Re: We're building a browser when it's supposed to be impossible
#345Earlier quoted context omitted.
It looks like they ported Qt to SerenityOS. I saw a package called "qt6-serenity". Perhaps they use the SerenityOS GUI libraries underneath. Does anyone know?
Ladybird is a browser based on SerenityOS technologies that uses Qt as the GUI framework. In SerenityOS, they have their own browser using the same underlying technologies, but a different in-house GUI framework. WebKit and Blink are similar in how they have their different counterparts like QtWebEngine or WebKitGTK. The equivalent to WebKit and Blink in SerenityOS is called LibWeb.
Hmm, I was actually asking if SerenityOS released a "fork" of Qt that re-implements class QPaint to use their native GUI API. I assume yes. QPaint is turtles all the way down to paint pixels on any platform -- MacOS, Win32, X Windows, Wayland, Android, iOS, embedded (auto), etc.
Re: We're building a browser when it's supposed to be impossible
#346Earlier quoted context omitted.
> On the web, you may get Twitter's feed rendering acceptably, and then two days later they ship an insignificant redesign that happens to use sixteen CSS features you don't have and everything is totally broken again. this is not directed at you, but at this attitude which is very common and which I see all the time: everyone is lightning fast to come up with reasons that something won't work. why? why do people say…
If you have infinite time and resources with perfect communication/understanding you can solve a lot of engineering problems. No one has that. This is where the original quoted claim from the article comes from, "building a web browser is impossible". That's encoding a lot of experience and reality of the Brobdingnagian challenge of building a web browser from scratch on 2023's web. It's not negativity to point out a…
not all positivity is toxic positivity, you know. I wasn't even positive, I was just anti-negative. being against negativity is not the same as being positive at all.
spouting out a problem you foresee being revealed after another problem is solved is not constructive criticism, it is reactionary and attention-seeking.
my comment is about comments like yours; unlimited time and energy to mention anything that makes what I say sound bad, improbable or difficult, and zero time or energy to even entertain the idea that my point of view is valid, and worth considering.
toxic negativity.
Re: We're building a browser when it's supposed to be impossible
#347Earlier quoted context omitted.
> 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…
> perhaps you could have an 'libhtml' for static sites and documents, and different ones for more interactive apps etc You mean, like a web-browser from the late 90's + Java WebStart?
ohgod
Re: We're building a browser when it's supposed to be impossible
#348Earlier quoted context omitted.
> perhaps you could have an 'libhtml' for static sites and documents, and different ones for more interactive apps etc You mean, like a web-browser from the late 90's + Java WebStart?
ohgod
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.)
Re: We're building a browser when it's supposed to be impossible
#349Earlier quoted context omitted.
Can you recommend a language that doesn't crash?
There are some languages that can be formally verified, and have themselves been formally verified. Formal verification is a complete pain in the ass to do and there's a reason it's mostly done only in the most critical of systems, but if a program passes 100% formal validation, you're as close to crash free as you can possibly be. I believe Ada and some other lesser used language sport well supported formal verifica…
Frama-C is used in production to meet normative requirements for critical software at least at Airbus (DO-178C), THALES (CC EAL6/7), EDF (ISO 60880). I think that they use actual software in production.