Live data from Hacker News

Grand Unification of Web Technologies Proposal

docs.google.com

41–50 of 85 posts

Re: Grand Unification of Web Technologies Proposal

#41

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 fri…

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.

Re: Grand Unification of Web Technologies Proposal

#42
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.

Now get off my lawn.

Re: Grand Unification of Web Technologies Proposal

#43

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.

Re: Grand Unification of Web Technologies Proposal

#44

Couldn't disagree more strongly. 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. (…

[deleted]

Re: Grand Unification of Web Technologies Proposal

#45
Couldn,t agree more.

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

Re: Grand Unification of Web Technologies Proposal

#46

Earlier quoted context omitted.

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 fri…

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 base…

Google's Fuchsia OS is based around some of your design concepts.

See: https://fuchsia.dev/fuchsia-src/concepts

Re: Grand Unification of Web Technologies Proposal

#47

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.

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?

Re: Grand Unification of Web Technologies Proposal

#48
post #20

https://github.com/w3c/csswg-drafts/issues/5743 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.

Could not find an ideological view there?

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

Re: Grand Unification of Web Technologies Proposal

#49

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.

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.

Re: Grand Unification of Web Technologies Proposal

#50
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.
Post reply on HN