Live data from Hacker News

Grand Unification of Web Technologies Proposal

docs.google.com

31–40 of 85 posts

Re: Grand Unification of Web Technologies Proposal

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

Re: Grand Unification of Web Technologies Proposal

#32

Seems like the worst possible idea. HTML and CSS are much more robust compared to Javascript, which is finicky at best.

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.

Re: Grand Unification of Web Technologies Proposal

#33
post #26

Earlier quoted context omitted.

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…

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…

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

:hands-up: Very nicely said.

Re: Grand Unification of Web Technologies Proposal

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

Re: Grand Unification of Web Technologies Proposal

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

[0] https://remaketheweb.com/ [1] https://docs.remaketheweb.com/

Re: Grand Unification of Web Technologies Proposal

#36

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. (…

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.

Re: Grand Unification of Web Technologies Proposal

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

Re: Grand Unification of Web Technologies Proposal

#38

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.

> This is not an appropriate venue to discuss replacing the entire web tech stack.

What an excellent response from the maintainers.

Re: Grand Unification of Web Technologies Proposal

#39
post #34

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

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.

Re: Grand Unification of Web Technologies Proposal

#40
post #30

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…

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.

Post reply on HN