It's interesting that no-one talks about writing new systems and base languages that don't inherit anything from the current toolchain. That's the first step, then new architectures / fully open auditable hardware basis. With html you don't need any of this dependency chain. As long as you can write a browser you can be running on anything underneath.
While it's hard to point to a fully top bottom initiative to create new platforms from the ground up, the Chinese appeared to be making an effort to reduce their non-native surfaces with things like Harmony OS.
A complete plan to reduce vulnerability from untoward influences is more feasible now with agent assisted engineering. You have to be carefully selective about what matters and what doesn't, or the cost and time balloon out of control.
That's also weird, in this reality, isn't it? You've got russians, chinese, etc, supposedly antagonistic to the western cultural hegemony, but then they just rely on western technology tool-chains. If I was guiding any of these countries a close to number 1 priority, technologically speaking, would be to create a completely independent software tool-chain. And talk through adaptors.
I think China uses NeoKylin, and Russia Astra Linux, both based on Linux.
I don't see China antagonistic to the west - they want autonomy, and don't share many of the values, but they're open to a wealthy West spending lots of money in Chinese goods.
Russia, at least its government, is a bit more, especially recently. But anyway, why reinvent the wheel when a battle tested FOSS is there for the taking?
At this point, a browser is a significant part of the way to being an OS virtualised inside the OS it's really running on. Complete with occasional leaks through the virtualisation to the real host OS/machine.
Yes, chrome for instance is more lines of code than the entirety of Linux, I think this just makes the case stronger for what I said. Although I understand why it might be so.
What do you mean with "don't inherit anything"? Using the existing binary ABI is mandatory for interoperability so yes, in that sense every new programming language inherits something. Other than that, there's plenty of languages that have fully self-contained toolchains and runtimes, e.g. Erlang and Rust come to mind. Guix bootstraps its entire environment from a minimal Lisp implementation. There's also Microsoft's CLR and its entire ecosystem of programming languages, but I don't know if the runtime exists next to the Win64 C/C++ base or on top of it.
HTML is entirely the wrong comparison as it's a document format and not a programming language, and "as long as you can write a browser" is not a simple condition. Do we have any browser (even in development) that isn't written with current toolchains? Or a headless javascript runtime perhaps?
HTML as the "transport"/"dialect" to keep compatibility with the existing computational world. What I mean is from the ground up, no C, no erlang (which Im a big fan of in terms of application organisation), no Rust, no Javascript. Start from first principles, OS'es closer to uni-kernels, sane sharing/privacy policies, ability for instance to start an "executable" (already an abstraction tied to the current mode of software production, albeit a perhaps useful one) with a narrow set of scoped access. Then it only has to implement a browser/subset of it to parse HTML and it can "access" most of the relevant parts of the existing software world (internet). Ditch anything complex, if necessary make a browser that just uses flexbox, no other things, no backwards, compatibility, if you need compatibility buy a normal laptop with a normal OS, that comes with all the cruft, but design this new one from the ground up.
But I also don't understand why (without compatibility layers) a browser should be as complex, or remotely as complex, as currently, specially with all the knowledge in hindsight.
I'm not saying this is easy, doable, or whatever, but that was what I meant.
Like linux is some bastion of security or something... I'm everyday more convinced that the reason why linux was let to dominate the server side with no contestation was so that the USA spy network could be done without compromising american companies. This is just the follow up of the same plan.
Does it really matter? Normal observation.
This post itself is already on the way to disappear... Farms bots everywhere, fake reviews, fake posts, fake experiences.
David Lynch was probably right, white fences, smiley families, but underneath a stench...
I think that this is also a matter of organisation that people can get better at if they understand a bit of how things come into place. If you start by creating a stable theme, with the spacings you want, the colors you want, fonts, sizings, etc, even using an AI, then you can "customise" in full the look of a web-app.
The html there's not really many places to be creative, a navbar with 3 sections, 5 links, a text card, a hero image, etc, all those are the same across thousands of projects - they're structured, there's not really many ways you can be creative about it. So in part seeing that "middle ground" design is indeed a filter for the lowest of the low effort (or not understanding how to prompt properly, or how the final thing comes together).
If you just want to prompt models and have them come up with more diverse styles that's also quite, or more, lazy - it would help if you understood (not you in particular) how the look of a web page comes together, because then you can direct the model properly - and if needed tweak the lose ends because at some point it's just easier and faster to edit the output yourself but you need to know what needs change and how. If you know how an html page comes together into the thing you see in the browser you can spec the model properly.
Because that's not the point. Before you could waste, without kidding, hours in meetings discussing css alignments, flows that didn't make sense but the upper levels were pretty serious about it - "Our QA and test groups say this is of the utmost importance", even when the QA and test groups were the same, 3 or 4 people that insisted on it.
I think most people, but at least I, could always deliver things inside schedules (not even set by myself) without a problem, even with those "adjustments" and changes of mind, and doubly so if I could just have the same leeway that now seems to be in place.
Nonetheless, if there's going to be a premium it has to be discernible in any particular way because software for business is always considered a cost. But what really shows this industry is half a joke, is that now there's no issue in giving 3rd party agents full access to inner code and logic, many times credentials too because these systems are being deployed in CIs. And because there's really no enforcement or punishment for leaks, or endangering users in most areas there's no reason for a premium. There's people pushing thousands of lines / min (and I think even the most professional people out there can't honestly keep up with it) although that isn't in itself meaning the overall security is worse than before, it just means that for the most part it's now un-auditable in any meaningful way.
Yeah, the dialog thing is extremely annoying... I use them, and I always have to have a work-around for when morphdom replaces the dom nodes of a dialog because it will just make it disappear ... `non-programmatic-open=true` would solve it - yes, it can have edge cases but then it's a matter of me programming correctly, instead of programming work-arounds every time I need it.
(preface by saying I use webcomponents regularly, I can show you a game that's currently online where they're used extensively)
I don't really understand why people are complaining that this is unmaintainable on the replies to this snippet but there's plenty of things with webcomponents in general that could be better done on the browser side.
For one the innerHTML (or some new method) should be able to reference a `template` directly. If you want to use templates you need to do:
And if you want to use templates then you need to render the templates in a part of the dom that is parsed before this JS is run - there's no way of specifying dependencies for this kind of things - which is a short-coming of the platform as a whole.
One the same topic there's no way of providing an url for retrieval of a fragment that contains templates and have it parsed directly and available to subsequent JS if you could do:
`` or doing `fetch("/my-endpoint/returns-templates.html", {DOCUMENT_ID="MAIN_FRAGMENTS")` would parse the result and make it available to the browser engine then you could have on subsequent JS:
reply