11 ms·

Grand Unification of Web Technologies Proposal

61 points by misthop 6y ago

mikece 6y ago
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?
jhardy54 6y ago
Haven't finished reading it yet, but this is an interesting take. I'm curious to hear what other folks think.
tobr 6y ago
Is this the canonical link? Google docs makes for abysmal reading on a small device. I see about four words per line on my phone.
- misthop 6y ago
  It is as far as I could track down
- kuu 6y ago
  Maybe better in outline?: https://outline.com/jvqduR https://outline.com/jvqduR
  - tobr 6y ago
    For the most part, but the code examples look worse.
filleokus 6y ago
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.
- phtrivier 6y ago
  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 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.
dep_b 6y ago
I'm just sad that this person has to build it's career on this stack knowing it could be so much better.
- galoisgirl 6y ago
  There are other jobs on other stacks out there.
eighteyes 6y ago
This document is an application
timw4mail 6y ago
Seems like the worst possible idea. HTML and CSS are much more robust compared to Javascript, which is finicky at best.
- maweki 6y 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.
recursivedoubts 6y ago
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. (That's exactly what I tried to do with https://htmx.org 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.
- w_t_payne 6y ago
  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..
- zackmorris 6y ago
  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.
- deleted 6y ago
  [deleted]
- pmarreck 6y ago
  100% agree that declarative-as-much-as-possible is waaaaay easier to maintain/grok than procedural-as-much-as-possible
mellosouls 6y ago
https://github.com/w3c/csswg-drafts/issues/5743 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.
- tomcam 6y ago
  Could not find an ideological view there?
  - mellosouls 6y ago
    (From the document) Scrap everything else go with JavaScript, which I assume is the language he's most familiar with. It's at least consistent with classic religious "my language is better than yours".
  - HelloNurse 6y ago
    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
rektide 6y ago
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.
- scrollaway 6y ago
  "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.
  - rektide 6y ago
    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.
deleted 6y ago
[deleted]
fabiofzero 6y ago
When all you have is a hammer, everything looks like a nail.
- scrollaway 6y ago
  When all you have is an idiom, every comment looks like an opportunity to repeat it.
tannhaeuser 6y ago
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.
- ratherbefuddled 6y ago
  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.
- ROARosen 6y ago
  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?
  - timw4mail 6y ago
    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.
    - ROARosen 6y ago
      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.
laszlokorte 6y ago
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.
pmayrgundter 6y ago
"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." Weirdly fascist. No thanks.
- JackFr 6y ago
  So we’ve got a vast and beautiful ecosystem that grew up in the cracks of our planned garden. Let’s scrap all that and build another planned garden.
thesuperbigfrog 6y ago
If the web is to be rebuilt from scratch, let's choose something that is not Javascript as the basis. Gary Bernhardt's WAT talk shows just how non-sensical Javascript can be: https://www.destroyallsoftware.com/talks/wat 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.)
iSoron 6y ago
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.
- HelloNurse 6y ago
  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.
FpUser 6y ago
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.
maweki 6y ago
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.
- sp332 6y ago
  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.
ollerac 6y ago
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/ https://remaketheweb.com/ [1] https://docs.remaketheweb.com/ https://docs.remaketheweb.com/
karmakaze 6y ago
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.
chaganated 6y ago
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.
blippage 6y ago
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.
- johnny22 6y ago
  HTTP is a stateless protocol, not HTML. Please don't confuse one for the other.
- galoisgirl 6y ago
  > All I really want from the web is You do know there are a few other people in this world, right?
ROARosen 6y ago
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
- jazzyjackson 6y ago
  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 :)
disambiguation 6y ago
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.
jopsen 6y ago
We sometimes seem to forget that not all websites have to be web apps. 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.
nemetroid 6y ago
If you're willing to remove your application engine from my document viewer, please go ahead.
troughway 6y ago
It's 2030. All your websites follow the GUWT, and you are happy.
RandyRanderson 6y ago
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". Yes, this person wants to replace html/css/Javascript with Javascript + stuff.
throwaware 6y ago
>After 30 years, developers are still struggling to build websites efficiently. 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).
drknow007 6y ago
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. 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!
- galoisgirl 6y ago
  > HTML and CSS are not clean, intuitive, or efficient beyond simple examples. 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-if-a-scrollbar-is-visible 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-flexbox-2chb https://dev.to/galoisgirl/how-to-finally-understand-css-flex...
galoisgirl 6y ago
Some of you have never had to install Flash in your browser and it shows. (Not you-you, proposal author-you.) Flash was one technology that handled content, presentation and logic.
pcstl 6y ago
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. The reason the web has become such a big deal is exactly that its development is not constrained by such thinking.

61 points by misthop 6y ago

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?

jhardy54 6y ago

Haven't finished reading it yet, but this is an interesting take. I'm curious to hear what other folks think.

tobr 6y ago

Is this the canonical link? Google docs makes for abysmal reading on a small device. I see about four words per line on my phone.

misthop 6y ago
It is as far as I could track down
kuu 6y ago
Maybe better in outline?: https://outline.com/jvqduR https://outline.com/jvqduR
- tobr 6y ago
  For the most part, but the code examples look worse.

filleokus 6y ago

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.

phtrivier 6y ago
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 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.

dep_b 6y ago

I'm just sad that this person has to build it's career on this stack knowing it could be so much better.

galoisgirl 6y ago
There are other jobs on other stacks out there.

eighteyes 6y ago

This document is an application

timw4mail 6y ago

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

maweki 6y 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.

recursivedoubts 6y ago

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. (That's exactly what I tried to do with https://htmx.org 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.

w_t_payne 6y ago
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..
zackmorris 6y ago
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.
deleted 6y ago
[deleted]
pmarreck 6y ago
100% agree that declarative-as-much-as-possible is waaaaay easier to maintain/grok than procedural-as-much-as-possible

mellosouls 6y ago

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

tomcam 6y ago
Could not find an ideological view there?
- mellosouls 6y ago
  (From the document) Scrap everything else go with JavaScript, which I assume is the language he's most familiar with. It's at least consistent with classic religious "my language is better than yours".
- HelloNurse 6y ago
  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

rektide 6y ago

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.

scrollaway 6y ago
"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.
- rektide 6y ago
  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.

deleted 6y ago

[deleted]

fabiofzero 6y ago

When all you have is a hammer, everything looks like a nail.

scrollaway 6y ago
When all you have is an idiom, every comment looks like an opportunity to repeat it.

tannhaeuser 6y ago

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.

ratherbefuddled 6y ago
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.
ROARosen 6y ago
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?
- timw4mail 6y ago
  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.
  - ROARosen 6y ago
    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.

laszlokorte 6y ago

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.

pmayrgundter 6y ago

"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." Weirdly fascist. No thanks.

JackFr 6y ago
So we’ve got a vast and beautiful ecosystem that grew up in the cracks of our planned garden. Let’s scrap all that and build another planned garden.

thesuperbigfrog 6y ago

If the web is to be rebuilt from scratch, let's choose something that is not Javascript as the basis. Gary Bernhardt's WAT talk shows just how non-sensical Javascript can be: https://www.destroyallsoftware.com/talks/wat 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.)

iSoron 6y ago

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.

HelloNurse 6y ago
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.

FpUser 6y ago

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.

maweki 6y ago

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.

sp332 6y ago
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.

ollerac 6y ago

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/ https://remaketheweb.com/ [1] https://docs.remaketheweb.com/ https://docs.remaketheweb.com/

karmakaze 6y ago

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.

chaganated 6y ago

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.

blippage 6y ago

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.

johnny22 6y ago
HTTP is a stateless protocol, not HTML. Please don't confuse one for the other.
galoisgirl 6y ago
> All I really want from the web is You do know there are a few other people in this world, right?

ROARosen 6y ago

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

jazzyjackson 6y ago
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 :)

disambiguation 6y ago

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.

jopsen 6y ago

We sometimes seem to forget that not all websites have to be web apps. 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.

nemetroid 6y ago

If you're willing to remove your application engine from my document viewer, please go ahead.

troughway 6y ago

It's 2030. All your websites follow the GUWT, and you are happy.

RandyRanderson 6y ago

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". Yes, this person wants to replace html/css/Javascript with Javascript + stuff.

throwaware 6y ago

>After 30 years, developers are still struggling to build websites efficiently. 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).

drknow007 6y ago

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

galoisgirl 6y ago
> HTML and CSS are not clean, intuitive, or efficient beyond simple examples. 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-if-a-scrollbar-is-visible 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-flexbox-2chb https://dev.to/galoisgirl/how-to-finally-understand-css-flex...

galoisgirl 6y ago

Some of you have never had to install Flash in your browser and it shows. (Not you-you, proposal author-you.) Flash was one technology that handled content, presentation and logic.

pcstl 6y ago

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. The reason the web has become such a big deal is exactly that its development is not constrained by such thinking.