Couldn't disagree more strongly.<p>The web worked because of its unique network architecture (REST/HATEOAS) which handles a chaotic, loosely coupled and dynamically evolving network topology extremely well.<p>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 <a href="https://htmx.org" rel="nofollow">https://htmx.org</a>, which just went 1.0 btw)<p>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.
"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."<p>Weirdly fascist. No thanks.
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.<p>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.
<a href="https://github.com/w3c/csswg-drafts/issues/5743" rel="nofollow">https://github.com/w3c/csswg-drafts/issues/5743</a><p>Appears to be a junior/intermediate dev with somewhat ambitious and rather ideological views.<p>That doesn't mean he's wrong but bear in mind the context of the enthusiasm and desire to change everything through JavaScript.
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.<p>> 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.<p>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.<p>I find this proposal gross & immoral.<p>> We need to realize that the approach to consider every single web page as a "document" rather than an "application", does not work anymore.<p>> For this, a website should be considered an application rather than a document.<p>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.<p>Further, we ought be using semantic web technology, to make well defined sub-documents on the page. Documents within documents.
If the web is to be rebuilt from scratch, let's choose something that is not Javascript as the basis.<p>Gary Bernhardt's WAT talk shows just how non-sensical Javascript can be:<p><a href="https://www.destroyallsoftware.com/talks/wat" rel="nofollow">https://www.destroyallsoftware.com/talks/wat</a><p>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.)
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.
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.<p>I wouldn't want my Browser to execute any layouting algorithm somebody sends to me.<p>The web has been successful because it was declarative. And most avenues where imperative solutions were necessary, were later fixed with declarative extensions.<p>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.<p>Implementing such a proposal based on a turing-complete imperative language would basically mean the end of the open web.
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.<p>Sure it is a mess if one wants to look for a mess but it benefits far outweigh its many problems.<p>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).<p>So back to the author of original article. In my opinion it is very arrogant, incompetent and naive (at best) piece.
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.
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.<p>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.<p>Why does my browser need to download fonts? I already have fonts. Just use those!<p>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.<p>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.<p>Now get off my lawn.
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?
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.<p>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.<p>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.
We sometimes seem to forget that not all websites have to be web apps.<p>It's fine that you can use JS or wasm, and if you really want to you barely need to touch html/css<p>But for many things, plain HTML with a bit of CSS and tiny amount of JS is perfectly fine.
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.<p>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.<p>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.<p>Large parts of its infrastructure were inspired by some excellent critiques of SPAs from this very message board:<p>- 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)<p>- 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.<p>- It uses a file-based JSON datastore so it's easier for devs to use and manipulate data<p>- It uses file-based routing, so there's no complex hierarchy of pages and a standard structure to URL params<p>- 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<p>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.<p>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.<p>[0] <a href="https://remaketheweb.com/" rel="nofollow">https://remaketheweb.com/</a>
[1] <a href="https://docs.remaketheweb.com/" rel="nofollow">https://docs.remaketheweb.com/</a>
Great job. I largely agree with the concepts in this well thought out paper. I have built several commercial grade products and the front-end is always where the most pain and cost exist. By a long shot. If someone doesn't agree this layer needs a serious overhaul, they are not the ones paying the bill or have not build a large scale commercial product.<p>HTML and CSS are not clean, intuitive, or efficient beyond simple examples. Masters of these tools sadly have their heads full of legacy hacks and trickery needed to get content to display properly. Thank goodness there has been some consolidation on the V8 engine because without it, the hacks between browsers had already become exponential.<p>Contrast this with algorithms, the middle-tier, and databases. These tools, while not perfect, are far better able to express developer intentions and therefore be maintained.<p>Sadly, the Web stack has largely become popular due to OS politics. JS/HTML/CSS is the only real loophole devs currently have to build cross-platform products, which everyone wants because the expectations from users today are so high (expected to run everywhere on any device). It is good that we at least have this direction to build upon, but it doesn't mean that this is the ideal tech stack. There is alot of improvement to be had here.<p>For example, consider how much good VS Code and Typescript have brought to this space in recent years. The concepts of types, intellisense, async/await, and other efficiencies are great examples of historically native benefits brought to the Web.<p>Good work here. Keep pressing on - I salute you. Please consider making any progress you have made here open for review and validation. Cheers!
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.<p>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.
Couldn,t agree more.<p>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.<p>We can even have a subset of JS to be used as some sort of <i>safe mode</i> which would only allow the representational parts to run.<p>Of course HTML can still exist, just as PDF still exists. But it shouldn't be <i>required</i>
I don't see the appeal. Converting HTML and CSS into JSON seems like a lateral move at best (disregarding the tools we have for authoring and accessibility), not forward.
>After 30 years, developers are still struggling to build websites efficiently.<p>Wrong. I could create a website very easily using FrontPage Express when I was a teenager. And today I can still build a website very easily using notepad or vim.<p>What's difficult is to emulate the user experience of a TV or an operating system using hypertext technologies (in the same way it's difficult to fix a car using cooking utensils).
This pretty much summarizes the academic mentality: Everything must be neat, tidy, and follow a well-defined formal process, preferably one defined by a committee that uses a lot of big words and stands above mere mortals.<p>The reason the web has become such a big deal is exactly that its development is not constrained by such thinking.
Some of you have never had to install Flash in your browser and it shows. (Not you-you, proposal author-you.)<p>Flash was one technology that handled content, presentation and logic.
I did a medium skim of the whole doc, so apologies if I missed anything.<p>The following is my TL;DR takeaway:<p>* 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.<p>* By consolidating, we eliminate redundancies across the front-end landscape.<p><pre><code> * 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.
</code></pre>
Reactions<p>* 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.<p>* 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! :)<p>Critiques<p>* Before the POC stage, special care has to go into deciding what bits of the declarative web are getting eliminated.<p><pre><code> * 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
</code></pre>
* Maybe I missed it, but there seems to be a bunch of other loose ends:<p><pre><code> * State-management
* inheritance (both state and style)
* rendering/lifecycles
</code></pre>
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.
TLDR: "After 30 years, developers are still struggling to build websites efficiently. Our hypothesis is that this is due to severe and acute design flaws in HTML, CSS, and the architecture of the web [...]. Our primary goal [...] is [...] the idea of a new, unified open web standard built around JavaScript".<p>Yes, this person wants to replace html/css/Javascript with Javascript + stuff.