Grand Unification of Web Technologies Proposal
docs.google.com
docs.google.com
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.
Weirdly fascist. No thanks.
Let’s scrap all that and build another planned garden.
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.
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 come up with 1000 lines of CSS that do the work of 10 lines of code.
Of course it will not happen, but it was nice to imagine that.
-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.
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.
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.
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.)
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?
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.
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 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.
I would want termination of the layouting process to be terminating.
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?
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'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.
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/
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.
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.
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.
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.
Good work here. Keep pressing on - I salute you. Please consider making any progress you have made here open for review and validation. Cheers!
They do have a steep learning curve. The web is polluted with tutorials and StackOverflow answers from people who haven't learned them yet, like this atrocious thread where most upvoted answers are plain wrong: https://stackoverflow.com/questions/4814398/how-can-i-check-...
> Masters of these tools sadly have their heads full of legacy hacks and trickery needed to get content to display properly.
The trickery is not needed anymore. I started in 1996 and I remember the table and float layouts. You can forget all this stuff now. IE11 supports flex-box well. Clean up your code and move on.
> 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.
Well, I did understand flex-box after thinking in terms of layouting algorithm instead of a bag of properties and values. [1] But you're dangerously close to comparing apples to oranges here: front-end technologies are all about the user's experience, not the developer's intent. If you feel that strongly about them, consider sticking to the back-end.
> Sadly, the Web stack has largely become popular due to OS politics
No, the web stack has become popular because of the people from your first paragraph: the ones paying the bills. The ones who couldn't afford to lose customers by requiring a plug-in, nor building multiple versions of the same product.
> The concepts of types, intellisense, async/await, and other efficiencies are great examples of historically native benefits brought to the Web.
Types? JavaScript is typed, always was. Ajax was always asynchronous - do you mean the syntactic sugar?
[1] I then wrote that: https://dev.to/galoisgirl/how-to-finally-understand-css-flex...
Agreed.
>> The trickery is not needed anymore...
This isn't needed (as much) today because of browser consolidation. The point is that these Web technologies were too difficult for browsers to maintain. The tech didn't get better. Instead, we had to minimize the # of containers in order to control the havoc.
>> ... But you're dangerously close to comparing apples to oranges here...
I'm not trying to directly compare layer tech here. Rather I'm comparing how well each layer's tools serve the developer and project. I'm not interested in a career move, thank you - lol. This thread is about best software strategies that have the responsibility of serving the world. Far more important stuff than me. It matters and is worth continuous re-assessment.
>> No, the web stack has become popular because of the people from your first paragraph: the ones paying the bills. The ones who couldn't afford to lose customers by requiring a plug-in...
Just not true. Historically, Web dev meant crazy amounts of code hacks in order to target different browsers. Again, it wasn't better tech - it was far worse and costly. Remember Flash, ActiveX, Silverlight, etc? Lots of successful sites and web apps used them to work around this problem.
Just stop and think about this. Flash devs didn't have to adapt their projects to their host container. It just worked. HTML/CSS/JS required lots more effort because of their intrinsic deficiencies. My point isn't that Flash (or anything else is better), its that HTML/CSS/JS is not where it needs to be, yet it still exists! And the reason it exists is because it runs on port 80! It's that simple - HTML/CSS/JS is one big loophole into x-platform development. Without this loophole, it loses much of its strategic appeal.
Again, I argue that devs really want to just use the tools they know and have their bits run everywhere. And 'everywhere' is a tall order because for today's consumers, this means total cross-platform on desktop, mobile, and web. Fast and fluid.
>> Types? JavaScript is typed, always was. Ajax was always asynchronous - do you mean the syntactic sugar?
Yes, I mean getting rid of the hacks and plethora of libraries needed to accomplish simple, age old software goals.
Imho, the Web stack has a real opportunity now to get focused and become a tech stack that most devs can love because it offers a x-platform strategy (although, importantly not because of HTML/CSS/JS - but because of port 80). But it needs to get better. It needs to get closer to the efficiencies and focus that native devs have been experiencing for decades. Cheers!
CSS and algorithms? Come on.
> Just not true. Historically, Web dev meant crazy amounts of code hacks in order to target different browsers. Again, it wasn't better tech - it was far worse and costly. Remember Flash, ActiveX, Silverlight, etc? Lots of successful sites and web apps used them to work around this problem.
I absolutely remember those, and they didn't work around the problem at all. You could not use Silverlight on Linux, you could use neither in text browsers nor on old machines, they weren't accessible,... The plug-in requirement itself scared many users away. I am so grateful to Steve Jobs for effectively killing those technologies.
> Yes, I mean getting rid of the hacks and plethora of libraries needed to accomplish simple, age old software goals.
Libraries are good, though JavaScript is in great need of a rich standard library, as problems with npm show. Hacks are arguable: how many were really necessary, and how many came from people who refused to learn the language well but pasted code samples from the web.
I'm not sure what you are missing here - I'm not directly comparing CSS and algorithms. Rather, I'm pointing out that the lower layers have tools that better allow their devs to express their intentions. The front-end does not do this well.
>> I absolutely remember those, and they didn't work around the problem at all...
For who? You? They absolutely solved several problems that existed with the Web stack. Why do you think they were created and used? I agree, the download requirement sucked, but that was because the plugin model of the browser sucked.
Your perspective seems too narrow here. Imagine if someone told you that you could build sites with your vanilla Web stack (HTML/CSS/JS), but you were not allowed to use 3rd party packages? Trust me, if Steve Jobs could close your Web stack too, he would. He would also close your hardware stack if he could. They are the least open company of them all for devs. Again, thank goodness for port 80!
>> I am so grateful to Steve Jobs for effectively killing those technologies...
Wow. Who are you to make a blanket statement like that? Are you suggesting that all the devs and projects that used those plugins simply didn't have a strategy and rather were too lazy to just learn the HTML/CSS/JS stack properly? Btw, many of these devs have a background in native development, which is typically a much more rigorous CS training - HTML/CSS/JS is not beyond them.
>> Libraries are good, though JavaScript is in great need of a rich standard library...
Agreed. You're making my point further. The Web stack is far behind native development in so many ways. However, port 80 is such a big deal (for bypassing OS politics), that it remains crucial that we try to embrace and improve upon it.
>> Hacks are arguable: how many were really necessary, and how many came from people who refused to learn the language well but pasted code samples from the web.
You're still making my point. This is an issue largely unique to Web development. With proper libraries and a more organized dev stack, these issues haven't existed for decades in native development. However, it does mean the Web community has conducted some really great experiments, which the original poster discusses.
Look... If you want to argue that the Web is great for static web pages, I will give you that. But only because its largely not complicated. However, if you want to argue that the Web is great for Web apps and positioned well for future software projects, then I would suggest you spend more time in the native world to gain a better appreciation for how much worse Web dev can be.
Finally, I believe front end development is not great no matter where you look. It's clearly a difficult layer to get right. This is why I stand with the intentions of the original post. The Web can build some great user experiences. But they are difficult to build, lack a consistent dev experience, and too often are full of hacks to get them to work.
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.
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 :)
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.
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).
The reason the web has become such a big deal is exactly that its development is not constrained by such thinking.
Flash was one technology that handled content, presentation and logic.
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.
* 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
* State-management
* inheritance (both state and style)
* rendering/lifecycles
Yes, this person wants to replace html/css/Javascript with Javascript + stuff.