I'm trying to show where it could go with htmx:
Hypermedia (in particular the uniform interface) is what made the web special and there's no reason HTML can't be improved as a hypermedia along the lines of htmx/unpoly/etc.
We don't need something new. We need to take the original concepts of the web (REST/HATEOAS/Hypermedia) seriously and push the folks in charge of HTML to do the same. Sure, browsers as install-free RPC client hosts works and is occasionally called for, but there is a huge gray area between "applications" and "documents", just waiting for a more expressive hypermedia.
I like Gemini, a lot, and I think it could serve as a "document web" very well, except it's missing certain document features like italics, bold and superscript. If you want a document format that serves the average user's needs, you need those features, period. With superscript you don't need inline links for citations.
An "application web" could just be a UI framework that renders an easy to write and read markup of some kind and fetches it over an internet protocol.
The problem with the distinction is it doesn't solve another core source of the problem, specifically, the reason document delivering websites send applications instead is that they want to track users and serve targeted ads. What's to stop CNN from just sending a message in your document web browser saying "please use your application web browser to view this page"? And that's precisely what they'll do, and then you're in the same boat we are in right now, minus the complexity possibly, and nobody will use the document web at all. How is this problem solved?
You might say there will be solutions like ideas to augment the canvas with meta data about what's in it but that IMO misses the point.
As a user I want to be in control of the data that's on my machine. With a standard like HTML, it allows me, as a user, far FAR more control then a native app. I can use userstyle sheets. I can write and/or install extensions that look through or manipulate the content. None of this is possible if all I get is a rectangle of pixels.
Translation and/or Language learning extensions would never have happened on native platforms because it's effectively impossible to peer into the app. Whereas it's super easy to peer into HTML based apps.
So, I like that most webapps work via HTML. I also like, that unlike most native UI frameworks, HTML has tons of relatively easy solutions for handling the differences between mobile and desktop. I've made several sites and web apps and while there may be a learning curve it's 2-3 orders of magnitude less work to get something working everywhere (desktop/tablet/mobile) with HTML than any other way of doing it.
Change to 2 modes, document mode, and app mode doesn't make sense to me. It'd be a net negative. People who want this I think want to take control away from the user. That's clearly Flutter's goal. All that canvas rendering means it's harder to select text, harder to copy and paste, impossible to augment via extension. It puts all the control in the app dev's hands and none in the user's.
So no, I don't want the web to be reinvented. Its provides something amazing that pretty much all attempts to replace it seems to missing. Its structure is a plus not a minus.
You have to start from the user's experience, because nothing else matters about a computer other than what you use it for. What do people actually want to do with a computer? It's going to be very hard to throw away all your assumptions. Don't assume that they want or need what we have today. They may not need the internet, or even a visual interface.
After you understand the problems the user wants solved, then you can go about building products that address those needs. You may think technology is clay that we can shape to fit a user's needs; but what if what they were best served by was metal, or glass, or paper? We must look through all technological mediums and components to provide the best solution.
Many of the developers today literally have never lived their lives in a world without certain inherent technological expectations and limitations. We need to open their minds and show them that they really can make literally anything with technology, and that it doesn't have to resemble anything that we have today. If you think "oh but we can't make change too radical, it wouldn't work", that's what they said before we ended up with the technology of today! The only box you're limited to is the one you put yourself in.
Its not 100% clear to me what the author's thesis is - but i think its that ever incrasing complexity of web standards results in bad user experience.
I dont think that is true - or as they say correlation does not equal causation.
The web used to be smaller and the corporate world didn't know what to do with it. It was creative and original. Eventually corporate america figured out what to do with it, and now it gets value extracted in a very impersonal way - as if your fave underground punk band sold out.
Complexity didn't cause this. It might be a symptom of this, but if the complexity went away, the corporization of the internet would still be there - the suits understand the internet now, and there is no stuffing that back in the bottle.
If neccessary, it would be entirely possible to recreate facebook in html 3.2. Its a social phenomenon not a technical one.
There is a single major problem: advertising. It is the default monetization path for most of the web, and it has become an unstoppable force of sites that are hostile to the user, siphon as much user data as possible, and use every marketing tactic available to trick the user into clicking on ads or agreeing to being tracked.
It has spawned a multi-billion dollar market of shady data brokers that sell user data to the highest bidder, and built an industry of adtech giants.
It has required passing laws to protect the user, and even those were late, not strict enough, impossible to enforce, and only available in small regions of the world.
It is pervasive and offensive, and this has to change. Progress is very slow on this front, but we need new monetization options that are as easy to use for both the user and content creator, and respect the user and their privacy rights.
Say what you want about Brave Inc., the BAT is the most compelling of such alternatives. It currently uses user-friendly ads, but those can be bypassed by funding the wallet instead.
I'm curious about other alternatives to advertising, not about another web framework.
The "document web" would be something very much like Google AMP. Those documents will need to be indexed so Google will get to choose what it looks like, what it does and how it tracks you. The "application web"... well, Apple could probably graft native app functionality into a URL, like App Clips. Google would do the same for Android, probably. Microsoft similar. Those three companies control the OSes everyone uses, so they'd get to choose.
And so on and so forth. More and more it feels like the web we have today is a miracle even though it's broken in many ways. We're very lucky to have a platform as open as the web is and we take it for granted at our peril.
This person needs to go look at some Geocities archives. People were trying to create cool-looking pages as soon as we had the IMG tag. People were using tables to organize a bunch of images in neat ways. People were doing weird little hypertext art things.
They were not using the technology in the "right" way. Nobody gave a shit about the right way. It took something like twenty fucking years for CSS to make it easy to vertically center shit the "right" way after persuading everyone that using tables for anything but tabular data was "wrong". If we waved a magic wand and suddenly everyone just had this theoretical Markdown-centric browser? People would immediately start looking for clever ways to abuse edge cases of its implementation to make their pages pretty. And people would start making enhancement requests, some of which the browser makers would inevitably implement, and... eventually we're right back where we are now.
I am not a fan of the modern corporate-dominated web, neither am I a fan of the modern world where more and more apps are horrible kludges of JS and HTML that have absolutely no care about the UI conventions of their host platforms, and are a couple orders of magnitude more resource-hungry than their equivalents that use native widgets and compiled languages. (Concrete example: Slack's 440 megs on disc, Discord's 370; Ripcord, a native app that talks to them both, is 40.) But thinking people will happily go back to a world with little to no control of the presentation layer after decades of struggle for more of that is a pipe dream. We all quit using Gopher the moment we had a web browser on our systems.
I like simple, and I like to be able to see changes I make in real time. React makes a lot of things more simple, so I use it often.
But maybe Markdown is the document language you're looking for? And to get started writing docs and code together, something like ObservableHQ is a pretty good way to go.
Previously discussed in: https://news.ycombinator.com/item?id=24255541 (117 points, 21 months ago, 90 comments)
The author makes a good start at fleshing out this argument, but stops short. He goes on to talk about a gizmo that was added to his own work to track use of a feature, which then was abused by others in the company.
The problem is that the same motivation and tools that are used by developers to figure out how to make their products better are the same motivations and tools used by advertisers to sell crap and snoop on users. Exactly the same tools, very different outcomes. One improves the experience while the other degrades it.
It's not clear how to separate the two, allowing only the "good" uses of tracking technologies while preventing the "bad." For its part, the essay doesn't really provide an answer so much as start talking about technologies.
But if you really want to improve the Web, it makes a lot of sense to really drill down into what makes the Web bad today. It is really technological complexity, leading to rendering engine monoculture? Or is it something more sociological in nature?
Then CSS needs to be trimmed down to basics too. Why is grid layout implemented in CSS instead of a <grid> tag, it doesnt make sense and is very hard to read.
Then there's the browser, which has remained fairly consistent and provides lots of functionality for navigation that is generally OK and well understood by people. SPAs destroy that by building another virtual machine layer on top of it (my pet peeve is ?force_cold_boot=1)
And then, why is WebRTC so complicated ? do we need to support all those codecs and nat traversal rules forever? Video communication should be as simple as adding a <videocall> tag
HTML should be readable by common people, they should be able to easily experiment with it, that's how the fun begins again
Just as described in the article: as soon as the opportunity presents itself, the business suits start mucking with the implementations and strategies, and at that point either the technically mature debating communicators step in and end the off-goal meddling or the entire process and effort is lost.
We do not have it in us anymore. We are not the generation that went to the moon. We're the consumer marketing ruined follow-on generation with a diverse mind filled to the brim with web3/crypto/socio-political-religious-end-of-the-world panic.
> Then, you need a browser.
I can't not think of the Alan Kay talk "The computer revolution hasnt happened yet" from 25 years ago. Some quotes:
"HTML on the internet has gone back to the dark ages because it presupposes there should be a browser that understands its format."
"...ever more complex HTML formats, ever more intractable."
"You don't need a web browser".
And in fact, this was correct? The model that we have, now has a spec so enormous, that it's common knowledge that it's impossible to build a new browser from scratch (although maybe somebody can prove common knowledge wrong). And having document nodes that create a DOM tree might be useful for... something... but it has proven to be a gigantic obstacle in delivering content on the web. Almost everything we do today tries to ditch this because it's just so complicated, but all the frameworks that work around this give us magic and deal with it in the background. It's therefore still slow and it will always be slow.
So maybe to fix things we should try something other than what we already had that didn't work.
An "URL" could instead be something like an application+datasource pair. The applications are automatically hashed and signed and you can provably verify they haven't changed if you want to. When you request an application to the network, you'll download it from the closest peer (maybe from multiple peers at the same time!). Since it's hashed and signed you only have to trust the signer.
Applications should be written in a single language, no more HTML+CSS+JS. Yes, we can and probably still should have separation between layout, style, and logic, but it should all just be in same language. In fact I've started exploring what that language could look like: https://flame.run/
Let's take the good parts of the current web and build a new foundation.
I like the web for different things but they are in a bit of a state of conflict. Things like Wikipedia are virtually unaffected by webassembly while things like Twitter and Facebook might make good use of it.
The future has yet to be written but like the article I kind of just know we are in a transition period from what we have to ...something.
That’s the only way monetization would work, other than selling personal data or relying on goodwill. And like it or not, profitability is a necessary part of writing for the web, for many people and almost all organizations.
It was a delightful foundation for the document web!
edit: added leak link.
edit 2: Turns out to be fake, confirmed by mozilla employee. Stupid 4chan.
> Rule #1 is don’t make a subset. If the replacement for the web is just whatever features were in Firefox 10 years ago, it’s not going to be a compelling vision.
If you don't want a subset, and you like markdown, then gemini seems like the answer. It is definitely gaining popularity but I'm not convinced it's enough to convert the general audience.
(+) stuff for me = websites, not web applications.
For Web applications, maybe all this vue / react / whatever stuff is worthwhile, I don't know, I'm not qualified to know (although let's face it, developers possibly might have a slight tendency to maybe over complicate things...just sometimes...)
But I struggle to see what in a normal website experience isn't more than provided by these basic tools.
Oh, and great content. None of any of this matters if you can't write...
The reason we got centralized was simply who pays to power the chips!
An app is an app, a website is a website, don't try to make them the same thing always.
WebAssembly is not a stand-alone application development package. It doesn’t have many of the functionalities of Flash, Applets, Silverlight or even NaCl. It has no API on its own to interact with display or keyboard and mouse. and none of the features you find in a VM such as multi threading or a memory allocator
It would also simpler for the app developers who would program against a simpler model than that of web apps.
And we can use the Web to deliver information i.e. documents.
Maybe I'm wrong here, but I struggle to see how one can arrive at that conclusion. I imagine a large percentage of users actively chose to not use Firefox over Safari because of it's integration and their familiarity.
HTTP and SMTP are fine however.
I have stopped coding .html and only use HTTP now from a native OpenGL client written in C.
It is untrue. You can write a plain HTML (even without CSS) and it will work OK.
> Webpage size growth is outpacing it all.
> Not only is it nearly impossible to build a new browser from scratch, once you have one the ongoing cost of keeping up with standards requires a full team of experts.
Yes, this is the real problem. However, some of the standards simply should not be implemented, and some should be implemented differently than what the standards say, to give advanced end users better controls and improve efficiency and many other things.
> We hope that all this innovation is for the user, but often it isn’t.
That is true, it isn't. To make it for the user, design the software for advanced users who are assumed to know what they are doing and that the end user customizes everything. Make documents without CSS; the end user can specify what colours/fonts they want. Make raw data files available; the end user might have programs to view and query them (possibly using SQLite).
> There is the “document web”, like blogs, news, Wikipedia, Twitter, Facebook.
> Basically CSS, which we now think of as a way for designers to add brand identity and tweak pixel-perfect details, was instead mostly a way of making plain documents readable and letting the readers of those documents customize how they looked.
I still often disable CSS, but sometimes result in big icons and other things still wasting space. Maybe if disabling CSS would support ARIA and other things might to actually make an improvement.
One idea that I have is that if your document only uses classless CSS and that a web browser that supports the semantic HTML commands (and not the presentational commands) should display it suitably, specify a feature="usercss" attribute in the <link> and/or <style> element that specifies the stylesheets, so that a web browser can understand to use it. This way, it will be up to the end user to set their own styles as they want to do and can effectively use it in favour of the author's one without breaking it.
> Though it’s going to be a rough ride in the current web which has basically thrown away semantic HTML as an idea.
Semantic HTML can be a good idea, and still is sometimes used, even if it is often ignored (and sometimes not implemented in the client side, too) in favour of bad stuff instead.
> Rule #3 is make it better for everyone. There should be a perk for everyone in the ecosystem: people making pages, people reading them, and people making the technology for them to be readable.
Yes, it is true. For people reading pages better, do not have any styles specified in the document. Let the end user to specify their own colours/fonts/etc, and different implementations can render them as appropriate for the interface in use.
> I think this combination would bring speed back, in a huge way. You could get a page on the screen in a fraction of the time of the web. The memory consumption could be tiny. It would be incredibly accessible, by default. You could make great-looking default stylesheets and share alternative user stylesheets. With dramatically limited scope, you could port it to all kinds of devices.
Yes, these are the greater benefits.
> What could aggregation look like? If web pages were more like documents than applications, we wouldn’t need RSS - websites would have an index that points to documents and a ‘reader’ could aggregate actual webpages by default.
Yes, that will work, although you may want metadata fields to be available. (An implementation might then allow end users to specify SQL to query them, or other things are possible.)
> We could link between the webs by using something like dat’s well-known file, or using the Accept header to create a browser that can accept HTML but prefers lightweight pages.
The documentation for dat's well-known file does not work (it just tries to redirect).
Using the Accept header is possible, but has its own issues. You might need to list one hundred different file formats to indicate all of them, you might want to download an arbitrary file regardless of Accept headers, etc.
> Application web 2.0
There are problems with the containers, web applications, etc, which is that they do not have the powers of UNIX, TRON, etc.
About separation of application web vs document web, I think that they should not be joined too closely together nor separately too far apart.
I have may own design which is VM3 (the name might or might not change in future), and we can then see what we will come up with. (It could be used with static document views only, executable codes with command-line or GUI or other interfaces, etc. The design is meant to improve portability and security, as well as user controls and capabilities.)