If the basic theory is that JavaScript dramatically out-performs CSS and HTML in a browser, why not compile your CSS, HTML, and JavaScript websites into pure JavaScript similar to how Kotlin or TypeScript are compiled to ECMAScript before publication?
Maybe the next step of the "web" is just to fully embrace the browser as an app VM. Have one standard for reading Wikipedia, and another for running Figma in the browser.
WASM + some common simple widget-esque API (like a small subset of Cocoa/GTK/QT). The browser provide implementations of some functionality like text-rendering and event handling, but then it's up to developer/frameworks to solve everything else.
I would argue that the web browser evolved, by accident, into the closest thing we have to a portable and usable desktop OS.
However, to me the browser is more like a "requirement statement", than a solution.
The success of the web is just a symptom that:
- users want applications that work on computers. Win vs Mac vs Linux vs Mobile vs ... is all nice and well for us geeks, but to real-world people, it's just a frigging computer.
For some reason, OS vendors were never able to agree on anything substantial, but browser vendors did.
We need a W3C for OSes. (Except, maybe one with a constitution, a parliament, a police force and a tax enforcement agency.) They have to decide an OS-level API.
They will probably fight over which programming language to use to write applications, but whatever they decide, someone will write a brainfuck compiler frontend for it, anyway, and it will not matter.
- users want to use applications, not spend hours installing them.
The browser got that right by accident, by using reflection and stringly-typing ; you 'install an application' by 'sharing a bit line of text that you can copy paste in an email', and you 'find an application' by typing a name in Google.
The browser stopped short of getting anything else right about application, feverishly waiting for someone to solve "librairies" for them by just downloading 100 versions of jquery and praying.
The OSes of the future will need interoperable, discoverable, namespaced apps, with namespaced, signed, shared libraries.
- users want applications with GUIs. And pretty much all applications will want to display the same basic suff that has been known since Smalltalk. (And the users don't really give a damn that the Facebook buttons do not look exactly the same as the Twitter buttons.)
The OSes of the future will need a standard way to draw the Smalltalk-level UIs.
And easily make the same application with a different logo on it, because the customer wanted Facebook, but more yellow.
- also, users wants games that just take all the screen and they could not give a damn about the buttons in the game, they want to play. And it should be fast.
The OSes of the future will need a standard way to use GPUs.
And, really, nothing else. The game devs don't really want an OS, actually. Ask Casey Muratori. Let the game devs do whatever they want with the computer, they know better than you, and will write semi-portable machine code (aka C) anyway. Your "browser" thingy would makes them laugh hard if they had the time to laugh while peeing in a jar to finish their next version of CoD.
- and users have a computer to do things with other people, so of course networking. What do you mean there are computers without networking ?
The OSes of the future will need networking. But since the people who designed ethernet and Internet and TCP/IP and routers etc... were border-line geniuses with infinite vision (apparently they were high on LSD most of the time), people will just use TCP/IP to communicate with our cousins of Mars.
But we'll have to come up with something better HTTP. And JSON.
And if we could let the OS handle network identity management ? So that all applications don't have to speed the first six months of development on the "login" page ?
Yes I know it's hard, but it's harder when it's not the right part of the computer doing it.
- and some, a tiny little portion of some users want to use computers to read the news. So, yeah, of course the OS would have shareable document reader. And those documents might very well be HTML (although, we all know that we need better.)
And the New York Times would build a "smalltalk-like app" to organise columns and images and typography and whatnot on an infinite canvas, and sometimes, display the text of an Op-ed - rather than turning the text of an Op-Ed into a weird tree of DOM elements, and have a poor soul c...
This is all pretty similar to what I've been imagining my ideal computing environment might look like.
-Applications as single-objects that are stored and manipulated the same as any other file
-Components (applications) compiled to some trivial-to-implement bytecode[0] as well as native
-User-malleable UIs where components are tied together with events, message passing, and or pipelines of some kind
-Public-key based network identity management
-Plan9-like ability to share resources over the network trivially
-Permissions applied between applications and resources instead of user and system
[0] This is so that new architectures can be bootstrapped easily and have access to the vast majority of tooling immediately. Native code could be included along side the universal bytecode for all currently-supported platforms.
I agree though that it is unlikely any of that will ever happen.
The web made sharing information easy. That's it. That's all it did. Without the web, if I wanted to share information with you, I'd have to learn C, OS native GUI libraries, TCP/IP, and probably a bunch of other stuff if my information also had picture and sound. On the web, I just need HTML and I'm already a published author.
What would a post-modern operating system need to do to make sharing information easy?
10 years ago if you had pitched this idea to Steve Jobs, he might have embraced it and pushed for a cross-platform app container standard that can run productivity apps, games and more. Perhaps we would have been living in a world where Apple does not take a 30% cut from all sales happening on the iPhone.
> Perhaps we would have been living in a world where Apple does not take a 30% cut from all sales happening on the iPhone.
We already do. Apple doesn’t take a cut of things you purchase in the browser. Nor do they take a cut of in-app purchases when it’s not consumed on the device for that matter.
This is by far my biggest gripe with Apple. Almost everything else they do can be justified by some mental gymnastics, but their suppression of the web on iOS is something I can't forgive.
The size of their user base demands that we don't ignore Safari when developing sites, but they simultaneously refuse to support modern standards. They are literally holding back the web.
And yet many of us prefer safari because of its incredible battery life and low overhead. The safari is the new ie meme is seriously overblown and only affects app developers trying to use the absolutely newest features and is more tied to safaris year long release cadence than actual malice. Not that there arent a few notable exceptions to apis that should have been implemented long ago.
Declarative descriptions are powerful and give safety guarantees by design. Doing everything in an imperative language makes basically every property undecidable.
I would want termination of the layouting process to be terminating.
The web worked because of its unique network architecture (REST/HATEOAS) which handles a chaotic, loosely coupled and dynamically evolving network topology extremely well.
The web suffered from the fact that HTML was a limited hypertext, which hurt usability and encouraged javascript-based work arounds. So we should fix that, rather than tossing the idea of a hypertext architecture. (That's exactly what I tried to do with https://htmx.org, which just went 1.0 btw)
There are tons of hacks and problems with layout and all the rest, but that has nothing to do with using javascript over the original hypertext model for the web. That's just how real world systems end up when they are the most successful network architecture ever devised.
HTMX is awesome, by the way. Thank you for making it!
I use it in combination with Python dominate and tailwind.css to write UI components that I can just plug together in a dataflow model at the back-end, and so far it's working amazingly well ... it's well on it's way to becoming a no-code application and UI framework..
Thank you, htmx looks conceptually more like the web should have been.
I wanted things like server side includes (SSI) on the frontend, so that we could swap out portions of pages (with security issues solved obviously). We could have also had subresource integrity (SRI), and included our Javascripts in pieces from anywhere based on their hash, rather than using Webpack. But instead we got the mess that is cross-origin resource sharing (CORS), which became such a frustration that we don't even blink at 10 MB app.js files.
We want a web that is declarative, data-driven and functional wherever possible. Which means that we should be moving away from asynchronous nondeterministic Javascript, not towards it. So ya, the article gets it almost completely backwards.
As already noted in other comments, the almost harmless technological subject matter underlines a genuinely fascist mindset (my idea is new, new ideas are good, unifying totalitarian new ideas are particularly good, old ideas are bad, fuck everyone else) and a fascist style (emphatic and disparaging language, strawman examples, proud and deliberate ignorance, loud but weak arguments).
Since this fascist approach to web design seems entirely due to naive enthusiasm rather than to the author being fascist about serious matters, it becomes a strong example of the temptation of being close-minded in order to move fast and break things.
Some citations:
> It is of utmost importance that the web should always be considered as one concept, one technology and one language, as this is the only way to avoid these unnecessary issues and to get clarity in the pursuit of substantial improvements.
> This proposal uses the scientific method as a guiding principle to analyze the current, mostly arbitrary rules of the three main web languages and reestablish them objectively and collectively. The more we can govern our principles and specifications by facts and logic rather than consensus, the simpler and easier it gets to improve upon them and to adopt them by everyone else.
> We need to realize that the approach to consider every single web page as a "document" rather than an "application", does not work anymore.
> Why do we allow innerHTML to branch out uncontrollably, but limit style to only one extra level? And if they are both branching, then why do they look so different?
> If we detach content and structure entirely, it becomes clear how damaging and limiting the architecture of the web has become. HTML is simply not suitable to remain the backbone of the web, this very concept is a logical contradiction (a metadata that has its own metadata). And this is not just something that limits us today, it will also undermine all future efforts to develop new ideas as well.
> Objects would allow an unprecedented level of consistency and simplicity across all major web technologies all the way from databases to the last bit of front end styling. But not only would this system be more uniform, it would also keep and even elevate the concept of separating the content, structure, styling and interactivity. Developers could segregate their objects into different files beyond this classification and create new grouping logic based on their needs. Some objects might be easier to work with if the styling or interactivity is already there, others might not require them at all.
> Let's imagine for a second that we are limited to only two position modes: absolute and fixed. No document flow, no Flexbox, nothing else, just these two. Any object we would want to put on screen would be equal in terms of positioning, but they would carry different content, just like in modern design softwares.
> This way we could build virtually anything, keeping everything fully responsive but at the same time simple and organized. Instead of holding back JavaScript and mimicking its functionality with CSS, we could just unleash it entirely and see the magic unfold.
> The Grand Unification is a big leap but a necessary one. HTML and CSS have reached its limits, developing them any further does not yield any additional benefit but demands more and more time and resources.
> HTML does a pretty bad job at categorizing its individual building blocks. In HTML we have content, normal tags, self-closing tags, elements and nodes but then we parse them all into the DOM that is made out of objects.
> Appendix 2 - Things that don't make any sense in CSS
Grand Appification of The Web proposal does not fill me with joy. It seems like a way to drag the web backwards, in to the murk & mire that is iconified by big monolithic large applications.
> The Grand Unification of Web Technologies is a proposal to unite all web technologies inside a browser creating a new, simple, more powerful and unified system. To achieve this, the functionality of HTML and CSS would be merged into JavaScript, a far superior technology, effectively obsoleting the other two.
The most user-hating proposal possible. Takes a huge case full of dynamite to the web being a place of documents, where there is well defined mark up that can be changed, & rebases the web to be hard to change, difficult, confusing javascript.
I find this proposal gross & immoral.
> We need to realize that the approach to consider every single web page as a "document" rather than an "application", does not work anymore.
> For this, a website should be considered an application rather than a document.
Web developers need to do a better job of using routers, such that the single page app does better align with documents, as the user expects. We should make things better, not dynamite documents.
Further, we ought be using semantic web technology, to make well defined sub-documents on the page. Documents within documents.
"gross and immoral" is uncalled for, and a pretty toxic way to start a conversation.
And you keep saying users "expect documents" but where is that coming from? Most users on the internet today do not expect documents. I'd argue they don't really expect apps either, webpages live in kind of a world of their own.
PS: I don't particularly care for this proposal, but clearly a lot of effort has gone into it and I find it "gross and immoral" to post comments dismissing it so thoughtlessly like this one.
I appreciate your attempt to be sensible & more moderate, but I don't feel like I'm overexaggerating my case. Yes, I could do a lot more work to support my case, to craft a more effective message. But this is immoral. It is highly destructive to user agency, to our ability to make extensions or to scrape pages. It is antitheical to freedom of thought, to our human liberties. I find the summation of what it implies to be a gross gross regression of human potential. Knuckling under something which is special, which is better, which has extensions, & making it become something pedestrian & mundane & inaccessible. It is gross, and to steal this power from the users would be immoral.
I have the same principles you do, but I think that battle is a losing one if you go at it with that mindset.
A lot of the web is already just javascript. Looking at "appification" and throwing our arms up in the air is just a form of giving up.
Rather, we should find ways to ensure that whatever direction the web takes, we can keep building powerful tools to foster the creativity and agency you and I have today, and push them to the hands of the mainstream.
> A lot of the web is already just javascript. Looking at "appification" and throwing our arms up in the air is just a form of giving up.
Yes, this certainly /feels/ like the trend. Yet folks like Github and Youtube and Microsoft are busy building a better web that does re-center & re-emphasize the DOM, by adopting & driving WebComponents forward.
It's weird to me that there is such a sizable disconnect: that a lot of very big very large players have adopted good web technology, but that so much of the world hasn't caught on, doesn't see it, doesn't know how they'd do it themselves. The lessons, of what large scale application design look like in such an environment, have not started disseminating out. The tools are there, but visualizing how they come together to make a web app, that's still fairly mysterious. But being done at very large scales, seemingly quite effectively.
> Rather, we should find ways to ensure that whatever direction the web takes, we can keep building powerful tools to foster the creativity and agency you and I have today, and push them to the hands of the mainstream.
> but clearly a lot of effort has gone into it and I find it "gross and immoral"
Wait until you find out how much effort goes into DRM schemes. It doesn’t make them any less anti-user which squarely lands in the immoral category for lots of people. Amount of effort and the engineering soundness of the design have no bearing on whether something is gross and/or immoral.
I’m refuting the argument that someone spending a lot of time and engineering on something means it can’t be dismissed as “gross an immoral”.
Proposing a system that destroys the open web with a bunch of applications that break link following, screen readers, text only browsers, etc is gross and immoral - no matter how sound the implementation.
Yeah, no. The web is precisely there for networked info/doc access. OTOH there never was a reason to take regular apps away into browsers; that's what OSes are for. Especially not when the lock-in detour through browsers also undermines the above-stated principal functions of the web.
I think there were lots of good reasons to have more layers of abstraction between apps and OSes - portability, security, ease of deployment to name the obvious ones.
Browsers were the wrong thing to target but they were the only thing getting even vaguely standardised across the proliferation of devices and OSes.
The problem I think was the pace. Nobody really had a chance to say "hang on folks, if we're going to do lots of this we need to talk about javascript and the DOM". Now we're stuck with it for good.
At this point the best we can hope for is to put a better layer on top and treat it as machine code.
Your talking the web of 1990-2010, fact is most websites today are heavily reliant on - or even exclusively created in - javascript.
Even if most websites wouldn't use the interactivity of JS, there is no reason for there to be three different standards. All those plain-text websites can be created in JSON just as well. The argument is, there is no need for plain HTML at this point, so why is this the base standard?
There is a need for plain HTML. HTML is robust, can render incrementally, and can stand on its own.
Javascript sucks. It's a subtle minefield of a language, takes more time to parse than HTML or CSS, and is by far the most brittle part of the website. Websites rendered only through Javascript are trash.
Whatever your dislike-level to JS is, we cannot dispute the fact that JS, or at least JSON can do pretty much everything HTML can do, but not the other way around.
Of course our beloved HTML can still exist, just as PDF exists. But in my opinion it shouldn't be the required standard. Since I can markup just as easily in JSON And like it or not JS is one the the core web components today, we can make JS the standard (we can keep it safe by allowing defining a safe subset of JS - e.g. JSON - which would work with general scripts disabled), with support for plain ol' HTML.
Point is, JSON can replace HTML, while preserving everything you like about HTML but not vice versa.
The JSON standard as is can not replace HTML because it has no room for error correction. Regardless of capability, one of the primary strengths of HTML is that it is forgiving at a syntax level. JS and JSON are not.
I still don't understand how people think they're going to build a website in pure JS.
I built a template preprocessor that lets me write all my HTML and CSS with the same syntax as a big JSON file, or a JS module if I want to drop in some loops and includes, and even working on replacing the JS with syntax that fits in the JSON file.
But I still need a way to think about "this box sits next to this box" and "this mask applies to all these boxes" -- what would I do without HTML?
why not just add new xml/cool-web-application content type to all browsers that lives in a parallel universes next to text/html and allows building rich UIs in wasm via nice modern api like for example flutter.
Then HTML/CSS/JS could be left alone for documents and hypertext based pages like wikipedia, blogs etc and stuff like googles docs or figma can be built in a new format.
And as both formats are supported by all browsers a document could just embed and xml/cool-web-application resource in an iframe and the application could just have a component to render an linked document.
"It is of utmost importance that the web should always be considered as one concept, one technology and one language, as this is the only way to avoid these unnecessary issues and to get clarity in the pursuit of substantial improvements."
If we are going to start over, let's design something that is better rather than choose the accidental winner that was hacked together in 11 days. (I love you, Javascript, but it's Stockholm syndrome.)
If this is such a great idea, I would recommend the author of this proposal to work instead on a transpiler that converts the proposed javascript-only websites into a mix of HTML+CSS+js. If the idea catches on and, at some point in the future, people start using the transpiler almost exclusively, then the web browser developers could add direct support, and even eventually phase out support for legacy individual HTML/CSS/js files. Another benefit of implementing a transpiler first is that it would make the proposed javascript-only approach usable today.
It's important to progress from impractical debate to practical technology, which needs to be proven.
I think authoring tools for the proposed non-markup would be even more challenging than transpiling tools; tag-based markup (HTML, XML, even SGML), actual JavaScript, TypeScript and variants thereof and CSS are all much more text-editor friendly than this verbose JSON variation.
The way web currently function in a browser: you can start with a simple piece of text readable everywhere and smoothly progress it up to a full blown application step by step. It is insanely creative and powerful paradigm that can be successfully used by everyone starting with my cat and ending with some genius programmer/artist/insert your own here.
Sure it is a mess if one wants to look for a mess but it benefits far outweigh its many problems.
Myself I mostly design native applications and servers but when I need to put some web fronts I am pleased on how relatively easy everything is (no I do not use giant web frameworks).
So back to the author of original article. In my opinion it is very arrogant, incompetent and naive (at best) piece.
A declarative description of what my machine should do with content I do not control is pretty important and gives important safety guarantees. We designed CSS, for example, to have a layouting algorithm that is limited in terms of backtracking (or disallows it) and is terminating.
I wouldn't want my Browser to execute any layouting algorithm somebody sends to me.
The web has been successful because it was declarative. And most avenues where imperative solutions were necessary, were later fixed with declarative extensions.
Once you're at the "just send me assembly"-level, every non-trivial property of the page is undecidable. And the declarative description of a website can be used by different renderers to generate something the user wants to see.
Implementing such a proposal based on a turing-complete imperative language would basically mean the end of the open web.
eBPF and rust show that it's possible to require programs to have certain provable properties, and still have enough flexibility to write really useful programs. WASM already avoids certain classes of bugs by controlling memory layout. And browsers warn if a JS script runs too long. We don't have to make software completely declarative to have safety guarantees.
I agree with the general principle of this document: HTML is outdated and there should be a unification of web technologies so the web becomes easier to build on.
My solution to this problem is to upgrade HTML, a language with a syntax I love, so it can handle building full-stack, interactive web apps instead of just plain documents.
I recently released my version of this idea as an open-source web app framework called Remake [0]. I could really use some help from contributors to make this new approach to building web apps even better. It's not meant to replace other stacks, but to complement them as an easy-to-learn, quick-to-build-with alternative.
Large parts of its infrastructure were inspired by some excellent critiques of SPAs from this very message board:
- It's a server-rendered framework (doesn't need front-end JS at all if a user is viewing a page they can't edit)
- It uses plain HTML, CSS, and JS to build out functionality (no transpilers and only the simple Handlebars.js templating language). You don't need a million tools to get started.
- It uses a file-based JSON datastore so it's easier for devs to use and manipulate data
- It uses file-based routing, so there's no complex hierarchy of pages and a standard structure to URL params
- It feels like, to me, the gold standard of web development: using a single templating and behavior-rich language on the front-end, and a simple JSON file for each user that's synced to and loaded automatically on the backend
I've been building it and documenting it [1] mostly on my own, although I've gotten a few other devs to help me along the way. I really think it could be a great framework for beginners as well as experienced developers who want to release small side projects quickly.
I've built several example apps with it so far and they're pretty powerful. I'd love to know what the HN audience thinks though.
I miss late 90s computing: native apps, with HTML as a document format rather than a VM. You could do interesting things outside of the google/http straightjacket. But none of that matters.
We have miscegenated disgusting javacript with the disgusting DOM, and we have filled the earth with it. It will be here forever! Like COBOL, but many orders of magnitude worse.
HTML is a stateless protocol Everyone is trying to turn the internet into an application server, which is stateful. Developing for the web is, therefore, necessarily complex, because you're trying to hammer a square peg into a round hole.
All I really want from the web is to READ documentation, look at cats and Youtube and do a bit of banking. HTML already caters for the first two categories. Why do we need stylesheets? HTML is a Markup Language. Just let the browser render the markup.
Why does my browser need to download fonts? I already have fonts. Just use those!
Computer folks can't leave well enough alone. We stuffed our web pages full of punch-a-monkeys (remember that egregious piece of garbage?) and Javascript. We put too much Javascript in, so now we're looking to "assemble" it.
Just get rid of it. Maybe a sprinkling - a SPRINKLING - of JS might help on some - SOME - sites. Some server-site scripting might be appropriate, too.
Factually, most websites created for presentation rather than documentation are wholly reliant on JS, even if they're structured to "also" work without JS (which itself shows you the issue.) So there's no reason not to create a standard from that for the future.
We can even have a subset of JS to be used as some sort of safe mode which would only allow the representational parts to run.
Of course HTML can still exist, just as PDF still exists. But it shouldn't be required
I already have "safe mode" it's called disabling javascript.
Anyway, I understand that there's dogma around how necessary javascript is so lets say we agreed -- how do you want to draw the website?
For me I've never met a better box model than HTML. Tried looking at qt and flutter but they feel like visual basic to me, a handful of components to arrange according to their rules. HTML is like paper, I can cut out pieces in whatever shape I want.
(Then again, it took me a long time to get my head around html/css so now I'm building a GUI/no-code site builder, but of course the output is HTML/SVG so it can render anywhere. And I only use JS to update attributes instead of waiting for a page reload. I figure if amazon.com can work without javascript, it must not be very necessary :)
I did a medium skim of the whole doc, so apologies if I missed anything.
The following is my TL;DR takeaway:
* Everything is consolidated into JSON. HTML and CSS elements are now expressed in a uniform JSON format. You can express a whole element (whole == styled + functional) as one JSON blob or define individual blobs and link them by class reference.
* By consolidating, we eliminate redundancies across the front-end landscape.
* I didn't see it explicitly, but I think it's implied that everything by default is a div, but you can define a "type" whether that's an "input" or a "style"
* CSS is called out as being too bloated and "functional", so his approach strips out everything from CSS that isn't basic cartesian positioning. The rest is deferred to javascript.
Reactions
* Overall I like it, very developer centric. I'm biased towards JSON > XML which is a plus. But just the idea of keeping track of one parser in my head for all of front end development, instead of the current 3, is a big win.
* IMO it seems like a lot of this could be achieved today in React, and It'd be cool to see a POC trans-piler that does exactly that! :)
Critiques
* Before the POC stage, special care has to go into deciding what bits of the declarative web are getting eliminated.
* ex. Relative positioning, if this gets removed I see it leading to a lot of "re-inventing the wheel" but maybe that's your intention? Everyone is already overly reliant on things like flex-box, so maybe this just results in flex-box-js :shrug
* Maybe I missed it, but there seems to be a bunch of other loose ends:
* State-management
* inheritance (both state and style)
* rendering/lifecycles
P.S. A lot of commentators are concerned you're trying to throw out the entire declarative web, but that wasn't my takeaway at all. Rather it's a call to refine the declarative foundation of the web.
84 comments
[ 2.7 ms ] story [ 147 ms ] threadWASM + some common simple widget-esque API (like a small subset of Cocoa/GTK/QT). The browser provide implementations of some functionality like text-rendering and event handling, but then it's up to developer/frameworks to solve everything else.
However, to me the browser is more like a "requirement statement", than a solution.
The success of the web is just a symptom that:
- users want applications that work on computers. Win vs Mac vs Linux vs Mobile vs ... is all nice and well for us geeks, but to real-world people, it's just a frigging computer.
For some reason, OS vendors were never able to agree on anything substantial, but browser vendors did.
We need a W3C for OSes. (Except, maybe one with a constitution, a parliament, a police force and a tax enforcement agency.) They have to decide an OS-level API.
They will probably fight over which programming language to use to write applications, but whatever they decide, someone will write a brainfuck compiler frontend for it, anyway, and it will not matter.
- users want to use applications, not spend hours installing them.
The browser got that right by accident, by using reflection and stringly-typing ; you 'install an application' by 'sharing a bit line of text that you can copy paste in an email', and you 'find an application' by typing a name in Google.
The browser stopped short of getting anything else right about application, feverishly waiting for someone to solve "librairies" for them by just downloading 100 versions of jquery and praying.
The OSes of the future will need interoperable, discoverable, namespaced apps, with namespaced, signed, shared libraries.
- users want applications with GUIs. And pretty much all applications will want to display the same basic suff that has been known since Smalltalk. (And the users don't really give a damn that the Facebook buttons do not look exactly the same as the Twitter buttons.)
The OSes of the future will need a standard way to draw the Smalltalk-level UIs. And easily make the same application with a different logo on it, because the customer wanted Facebook, but more yellow.
- also, users wants games that just take all the screen and they could not give a damn about the buttons in the game, they want to play. And it should be fast.
The OSes of the future will need a standard way to use GPUs. And, really, nothing else. The game devs don't really want an OS, actually. Ask Casey Muratori. Let the game devs do whatever they want with the computer, they know better than you, and will write semi-portable machine code (aka C) anyway. Your "browser" thingy would makes them laugh hard if they had the time to laugh while peeing in a jar to finish their next version of CoD.
- and users have a computer to do things with other people, so of course networking. What do you mean there are computers without networking ?
The OSes of the future will need networking. But since the people who designed ethernet and Internet and TCP/IP and routers etc... were border-line geniuses with infinite vision (apparently they were high on LSD most of the time), people will just use TCP/IP to communicate with our cousins of Mars. But we'll have to come up with something better HTTP. And JSON.
And if we could let the OS handle network identity management ? So that all applications don't have to speed the first six months of development on the "login" page ? Yes I know it's hard, but it's harder when it's not the right part of the computer doing it.
- and some, a tiny little portion of some users want to use computers to read the news. So, yeah, of course the OS would have shareable document reader. And those documents might very well be HTML (although, we all know that we need better.) And the New York Times would build a "smalltalk-like app" to organise columns and images and typography and whatnot on an infinite canvas, and sometimes, display the text of an Op-ed - rather than turning the text of an Op-Ed into a weird tree of DOM elements, and have a poor soul c...
-Applications as single-objects that are stored and manipulated the same as any other file
-Components (applications) compiled to some trivial-to-implement bytecode[0] as well as native
-User-malleable UIs where components are tied together with events, message passing, and or pipelines of some kind
-Public-key based network identity management
-Plan9-like ability to share resources over the network trivially
-Permissions applied between applications and resources instead of user and system
[0] This is so that new architectures can be bootstrapped easily and have access to the vast majority of tooling immediately. Native code could be included along side the universal bytecode for all currently-supported platforms.
I agree though that it is unlikely any of that will ever happen.
See: https://fuchsia.dev/fuchsia-src/concepts
https://en.wikipedia.org/wiki/Inferno_(operating_system)
https://en.wikipedia.org/wiki/Amoeba_(operating_system)
https://github.com/void4/notes/issues/41
What would a post-modern operating system need to do to make sharing information easy?
We already do. Apple doesn’t take a cut of things you purchase in the browser. Nor do they take a cut of in-app purchases when it’s not consumed on the device for that matter.
The size of their user base demands that we don't ignore Safari when developing sites, but they simultaneously refuse to support modern standards. They are literally holding back the web.
I would want termination of the layouting process to be terminating.
The web worked because of its unique network architecture (REST/HATEOAS) which handles a chaotic, loosely coupled and dynamically evolving network topology extremely well.
The web suffered from the fact that HTML was a limited hypertext, which hurt usability and encouraged javascript-based work arounds. So we should fix that, rather than tossing the idea of a hypertext architecture. (That's exactly what I tried to do with https://htmx.org, which just went 1.0 btw)
There are tons of hacks and problems with layout and all the rest, but that has nothing to do with using javascript over the original hypertext model for the web. That's just how real world systems end up when they are the most successful network architecture ever devised.
I use it in combination with Python dominate and tailwind.css to write UI components that I can just plug together in a dataflow model at the back-end, and so far it's working amazingly well ... it's well on it's way to becoming a no-code application and UI framework..
I wanted things like server side includes (SSI) on the frontend, so that we could swap out portions of pages (with security issues solved obviously). We could have also had subresource integrity (SRI), and included our Javascripts in pieces from anywhere based on their hash, rather than using Webpack. But instead we got the mess that is cross-origin resource sharing (CORS), which became such a frustration that we don't even blink at 10 MB app.js files.
We want a web that is declarative, data-driven and functional wherever possible. Which means that we should be moving away from asynchronous nondeterministic Javascript, not towards it. So ya, the article gets it almost completely backwards.
Appears to be a junior/intermediate dev with somewhat ambitious and rather ideological views.
That doesn't mean he's wrong but bear in mind the context of the enthusiasm and desire to change everything through JavaScript.
It's at least consistent with classic religious "my language is better than yours".
Since this fascist approach to web design seems entirely due to naive enthusiasm rather than to the author being fascist about serious matters, it becomes a strong example of the temptation of being close-minded in order to move fast and break things.
Some citations:
> It is of utmost importance that the web should always be considered as one concept, one technology and one language, as this is the only way to avoid these unnecessary issues and to get clarity in the pursuit of substantial improvements.
> This proposal uses the scientific method as a guiding principle to analyze the current, mostly arbitrary rules of the three main web languages and reestablish them objectively and collectively. The more we can govern our principles and specifications by facts and logic rather than consensus, the simpler and easier it gets to improve upon them and to adopt them by everyone else.
> We need to realize that the approach to consider every single web page as a "document" rather than an "application", does not work anymore.
> Why do we allow innerHTML to branch out uncontrollably, but limit style to only one extra level? And if they are both branching, then why do they look so different?
> If we detach content and structure entirely, it becomes clear how damaging and limiting the architecture of the web has become. HTML is simply not suitable to remain the backbone of the web, this very concept is a logical contradiction (a metadata that has its own metadata). And this is not just something that limits us today, it will also undermine all future efforts to develop new ideas as well.
> Objects would allow an unprecedented level of consistency and simplicity across all major web technologies all the way from databases to the last bit of front end styling. But not only would this system be more uniform, it would also keep and even elevate the concept of separating the content, structure, styling and interactivity. Developers could segregate their objects into different files beyond this classification and create new grouping logic based on their needs. Some objects might be easier to work with if the styling or interactivity is already there, others might not require them at all.
> Let's imagine for a second that we are limited to only two position modes: absolute and fixed. No document flow, no Flexbox, nothing else, just these two. Any object we would want to put on screen would be equal in terms of positioning, but they would carry different content, just like in modern design softwares.
> This way we could build virtually anything, keeping everything fully responsive but at the same time simple and organized. Instead of holding back JavaScript and mimicking its functionality with CSS, we could just unleash it entirely and see the magic unfold.
> The Grand Unification is a big leap but a necessary one. HTML and CSS have reached its limits, developing them any further does not yield any additional benefit but demands more and more time and resources.
> HTML does a pretty bad job at categorizing its individual building blocks. In HTML we have content, normal tags, self-closing tags, elements and nodes but then we parse them all into the DOM that is made out of objects.
> Appendix 2 - Things that don't make any sense in CSS
What an excellent response from the maintainers.
> The Grand Unification of Web Technologies is a proposal to unite all web technologies inside a browser creating a new, simple, more powerful and unified system. To achieve this, the functionality of HTML and CSS would be merged into JavaScript, a far superior technology, effectively obsoleting the other two.
The most user-hating proposal possible. Takes a huge case full of dynamite to the web being a place of documents, where there is well defined mark up that can be changed, & rebases the web to be hard to change, difficult, confusing javascript.
I find this proposal gross & immoral.
> We need to realize that the approach to consider every single web page as a "document" rather than an "application", does not work anymore.
> For this, a website should be considered an application rather than a document.
Web developers need to do a better job of using routers, such that the single page app does better align with documents, as the user expects. We should make things better, not dynamite documents.
Further, we ought be using semantic web technology, to make well defined sub-documents on the page. Documents within documents.
And you keep saying users "expect documents" but where is that coming from? Most users on the internet today do not expect documents. I'd argue they don't really expect apps either, webpages live in kind of a world of their own.
PS: I don't particularly care for this proposal, but clearly a lot of effort has gone into it and I find it "gross and immoral" to post comments dismissing it so thoughtlessly like this one.
A lot of the web is already just javascript. Looking at "appification" and throwing our arms up in the air is just a form of giving up.
Rather, we should find ways to ensure that whatever direction the web takes, we can keep building powerful tools to foster the creativity and agency you and I have today, and push them to the hands of the mainstream.
Yes, this certainly /feels/ like the trend. Yet folks like Github and Youtube and Microsoft are busy building a better web that does re-center & re-emphasize the DOM, by adopting & driving WebComponents forward.
It's weird to me that there is such a sizable disconnect: that a lot of very big very large players have adopted good web technology, but that so much of the world hasn't caught on, doesn't see it, doesn't know how they'd do it themselves. The lessons, of what large scale application design look like in such an environment, have not started disseminating out. The tools are there, but visualizing how they come together to make a web app, that's still fairly mysterious. But being done at very large scales, seemingly quite effectively.
> Rather, we should find ways to ensure that whatever direction the web takes, we can keep building powerful tools to foster the creativity and agency you and I have today, and push them to the hands of the mainstream.
:hands-up: Very nicely said.
Wait until you find out how much effort goes into DRM schemes. It doesn’t make them any less anti-user which squarely lands in the immoral category for lots of people. Amount of effort and the engineering soundness of the design have no bearing on whether something is gross and/or immoral.
do you even have an argument here?
Proposing a system that destroys the open web with a bunch of applications that break link following, screen readers, text only browsers, etc is gross and immoral - no matter how sound the implementation.
Browsers were the wrong thing to target but they were the only thing getting even vaguely standardised across the proliferation of devices and OSes.
The problem I think was the pace. Nobody really had a chance to say "hang on folks, if we're going to do lots of this we need to talk about javascript and the DOM". Now we're stuck with it for good.
At this point the best we can hope for is to put a better layer on top and treat it as machine code.
Even if most websites wouldn't use the interactivity of JS, there is no reason for there to be three different standards. All those plain-text websites can be created in JSON just as well. The argument is, there is no need for plain HTML at this point, so why is this the base standard?
Javascript sucks. It's a subtle minefield of a language, takes more time to parse than HTML or CSS, and is by far the most brittle part of the website. Websites rendered only through Javascript are trash.
Of course our beloved HTML can still exist, just as PDF exists. But in my opinion it shouldn't be the required standard. Since I can markup just as easily in JSON And like it or not JS is one the the core web components today, we can make JS the standard (we can keep it safe by allowing defining a safe subset of JS - e.g. JSON - which would work with general scripts disabled), with support for plain ol' HTML.
Point is, JSON can replace HTML, while preserving everything you like about HTML but not vice versa.
I built a template preprocessor that lets me write all my HTML and CSS with the same syntax as a big JSON file, or a JS module if I want to drop in some loops and includes, and even working on replacing the JS with syntax that fits in the JSON file.
But I still need a way to think about "this box sits next to this box" and "this mask applies to all these boxes" -- what would I do without HTML?
Then HTML/CSS/JS could be left alone for documents and hypertext based pages like wikipedia, blogs etc and stuff like googles docs or figma can be built in a new format.
And as both formats are supported by all browsers a document could just embed and xml/cool-web-application resource in an iframe and the application could just have a component to render an linked document.
Weirdly fascist. No thanks.
Let’s scrap all that and build another planned garden.
Gary Bernhardt's WAT talk shows just how non-sensical Javascript can be:
https://www.destroyallsoftware.com/talks/wat
If we are going to start over, let's design something that is better rather than choose the accidental winner that was hacked together in 11 days. (I love you, Javascript, but it's Stockholm syndrome.)
I think authoring tools for the proposed non-markup would be even more challenging than transpiling tools; tag-based markup (HTML, XML, even SGML), actual JavaScript, TypeScript and variants thereof and CSS are all much more text-editor friendly than this verbose JSON variation.
Sure it is a mess if one wants to look for a mess but it benefits far outweigh its many problems.
Myself I mostly design native applications and servers but when I need to put some web fronts I am pleased on how relatively easy everything is (no I do not use giant web frameworks).
So back to the author of original article. In my opinion it is very arrogant, incompetent and naive (at best) piece.
I wouldn't want my Browser to execute any layouting algorithm somebody sends to me.
The web has been successful because it was declarative. And most avenues where imperative solutions were necessary, were later fixed with declarative extensions.
Once you're at the "just send me assembly"-level, every non-trivial property of the page is undecidable. And the declarative description of a website can be used by different renderers to generate something the user wants to see.
Implementing such a proposal based on a turing-complete imperative language would basically mean the end of the open web.
My solution to this problem is to upgrade HTML, a language with a syntax I love, so it can handle building full-stack, interactive web apps instead of just plain documents.
I recently released my version of this idea as an open-source web app framework called Remake [0]. I could really use some help from contributors to make this new approach to building web apps even better. It's not meant to replace other stacks, but to complement them as an easy-to-learn, quick-to-build-with alternative.
Large parts of its infrastructure were inspired by some excellent critiques of SPAs from this very message board:
- It's a server-rendered framework (doesn't need front-end JS at all if a user is viewing a page they can't edit)
- It uses plain HTML, CSS, and JS to build out functionality (no transpilers and only the simple Handlebars.js templating language). You don't need a million tools to get started.
- It uses a file-based JSON datastore so it's easier for devs to use and manipulate data
- It uses file-based routing, so there's no complex hierarchy of pages and a standard structure to URL params
- It feels like, to me, the gold standard of web development: using a single templating and behavior-rich language on the front-end, and a simple JSON file for each user that's synced to and loaded automatically on the backend
I've been building it and documenting it [1] mostly on my own, although I've gotten a few other devs to help me along the way. I really think it could be a great framework for beginners as well as experienced developers who want to release small side projects quickly.
I've built several example apps with it so far and they're pretty powerful. I'd love to know what the HN audience thinks though.
[0] https://remaketheweb.com/ [1] https://docs.remaketheweb.com/
We have miscegenated disgusting javacript with the disgusting DOM, and we have filled the earth with it. It will be here forever! Like COBOL, but many orders of magnitude worse.
All I really want from the web is to READ documentation, look at cats and Youtube and do a bit of banking. HTML already caters for the first two categories. Why do we need stylesheets? HTML is a Markup Language. Just let the browser render the markup.
Why does my browser need to download fonts? I already have fonts. Just use those!
Computer folks can't leave well enough alone. We stuffed our web pages full of punch-a-monkeys (remember that egregious piece of garbage?) and Javascript. We put too much Javascript in, so now we're looking to "assemble" it.
Just get rid of it. Maybe a sprinkling - a SPRINKLING - of JS might help on some - SOME - sites. Some server-site scripting might be appropriate, too.
Now get off my lawn.
You do know there are a few other people in this world, right?
Factually, most websites created for presentation rather than documentation are wholly reliant on JS, even if they're structured to "also" work without JS (which itself shows you the issue.) So there's no reason not to create a standard from that for the future.
We can even have a subset of JS to be used as some sort of safe mode which would only allow the representational parts to run.
Of course HTML can still exist, just as PDF still exists. But it shouldn't be required
Anyway, I understand that there's dogma around how necessary javascript is so lets say we agreed -- how do you want to draw the website?
For me I've never met a better box model than HTML. Tried looking at qt and flutter but they feel like visual basic to me, a handful of components to arrange according to their rules. HTML is like paper, I can cut out pieces in whatever shape I want.
(Then again, it took me a long time to get my head around html/css so now I'm building a GUI/no-code site builder, but of course the output is HTML/SVG so it can render anywhere. And I only use JS to update attributes instead of waiting for a page reload. I figure if amazon.com can work without javascript, it must not be very necessary :)
The following is my TL;DR takeaway:
* Everything is consolidated into JSON. HTML and CSS elements are now expressed in a uniform JSON format. You can express a whole element (whole == styled + functional) as one JSON blob or define individual blobs and link them by class reference.
* By consolidating, we eliminate redundancies across the front-end landscape.
Reactions* Overall I like it, very developer centric. I'm biased towards JSON > XML which is a plus. But just the idea of keeping track of one parser in my head for all of front end development, instead of the current 3, is a big win.
* IMO it seems like a lot of this could be achieved today in React, and It'd be cool to see a POC trans-piler that does exactly that! :)
Critiques
* Before the POC stage, special care has to go into deciding what bits of the declarative web are getting eliminated.
* Maybe I missed it, but there seems to be a bunch of other loose ends: P.S. A lot of commentators are concerned you're trying to throw out the entire declarative web, but that wasn't my takeaway at all. Rather it's a call to refine the declarative foundation of the web.It's fine that you can use JS or wasm, and if you really want to you barely need to touch html/css
But for many things, plain HTML with a bit of CSS and tiny amount of JS is perfectly fine.