18 ms·

A clean start for the web (2020)

290 points by dannyow 4y ago

b1n 4y ago
This is an idea whose time has come.
- chris123 4y ago
  The road to hell is paved with good intentions and do-gooders.
deleted 4y ago
[deleted]
5350-uiop-1130 4y ago
Just stop building your web "apps" on the client side. Why should I pay to save on your server costs. An app is an app, a website is a website, don't try to make them the same thing always.
skybrian 4y ago
The web is far too big to invent all at once. Evolution is how it's going to go from now on. Good ideas will start out in niches. 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.
0xbadcafebee 4y ago
Do we really want to continue having "a web" ? Remember, "the web" was never designed for what we do with it today. If you're thinking of overhauling "the web", I think it makes sense to start from first principles, and build something that meets today's needs with the least amount of unnecessary bullshit. 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.
- deleted 4y ago
  [deleted]
- rektide 4y ago
  What feels unique about the web, that nothing else remotely resembles that makes it so much more compelling to me versus everything which came before, is urls. The web is a network of online resources. There's HTML, an ok, fairly adaptable hyper-media markup- and CSS, and scripts, all fair or better- but the premise turns everything else we do in computing on it's head: servers send us resources, and we have a (imo pretty great) engine to render & execute our hypermedia. I see endless torrents of anti-web attitude, from people who want more content-centric systems, from people who want applications. But almost never can the critics identify & mark out what makes the web better, different, & so flexible as to have arisen into all-pervading ubiquitous. By all means, consider first principles. I think you all have a lot of very important & enabling concepts you'll need to recreate along the way. The web's idea of urls & resources is one I think we'll have a hard time replacing.
  - zzo38computer 4y ago
    While there are some good ideas, there are also many bad ones. (URLs are one good idea.) It could be designed better. Perhaps I can mention this quotation (which wasn't about HTML, although some of the bad things happen with HTML for similar reasons): The sad fact of the matter is that people play politics with standards to gain commercial advantage, and the result is that end users suffer the consequences. This is the case with character encoding for computer systems, and it is even more the case with HDTV.
    - rektide 4y ago
      It mostly works pretty great. It's immensely popular to hate on.
- EddieDante 4y ago
  > Do we really want to continue having "a web"? Speaking only for myself, I'm not at all invested in having a website. Yes, I want a publicly accessible site of my own on the internet with which to share documents, and I currently do so over HTTP, but I would equally happy to share them over Gopher or even anonymous FTP. However, I'd rather pay NearlyFreeSpeech.net for hosting than run my own VPS or self-host on a machine in my basement because I'm lazy, so I'm stuck with HTTP because they explicitly don't support anonymous FTP (and by implication don't support Gopher or Gemini).
rektide 4y ago
(2020). Editorialized title ("A Clean Start for the Web"). Previously discussed in: https://news.ycombinator.com/item?id=24255541 https://news.ycombinator.com/item?id=24255541 (117 points, 21 months ago, 90 comments)
- dang 4y ago
  Thanks! Macroexpanded: A Clean Start for the Web - https://news.ycombinator.com/item?id=24255541 https://news.ycombinator.com/item?id=24255541 - Aug 2020 (90 comments) A Clean Start for the Web - https://news.ycombinator.com/item?id=24250252 https://news.ycombinator.com/item?id=24250252 - Aug 2020 (1 comment) A Clean Start for the Web - https://news.ycombinator.com/item?id=24247362 https://news.ycombinator.com/item?id=24247362 - Aug 2020 (3 comments)
jonny_eh 4y ago
The digital equivalent of "we screwed up Earth, let's go to Mars and screw things up all over again!"
egypturnash 4y ago
"But the early web wasn’t fun in many conventional ways - you couldn’t quite create art there, or use it as much more than a way of sharing documents." 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.
- enobrev 4y ago
  It's a beautiful thing. I remember the days you speak of. I also remember the leaps and bounds people took to bend myspace to their will. All for expression. It's been a beautiful and very human journey I'm not sure we would have gotten where we are now without those limitations for people to conquer. There's nothing in http that requires a browser. We could have released multiple app platforms by now. But there's a magic in html, css, and js that is taken completely for granted. I remain a fan. ...Edit to add that we have added these platforms. And they can't come close to what we have on the web. Roku, Apple TV, Nvidia Shield. These are application platforms. And they're ok for what they are. Android and IOS are the most successful connected platforms we have, and they're impressive, but I still spend more time in my browser than anything else on my mobile device.
pronlover723 4y ago
I think the web is mostly good the way it is and I don't want to see it re-invented. In fact, I hate Flutter because it's not "webby". It renderers all content and controls using Canvas which means all there is on the page is pixels which means no accessibility since there is no standard structure (the DOM) to dig through to find the content. 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.
- krapp 4y ago
  I have yet to see a suggestion to "reinvent" the web that expands on publisher or end-user capabilities, rather than taking them away. The end user doesn't want Geminispace, they don't hate that web publishers get to control layout and design, or that sites can be more complex than even the early web allowed. They don't want to write their own clients or stylesheets, they don't want the web to only be strictly static documents, with "apps" quarantined elsewhere. They don't want a different markup language. They don't want to destroy social media and force services not to use algorithmic feeds or discovery because it's "mind control." They don't want to kill all advertising and commerce on the web in the belief that content creators should be forced to work for love instead of money. I mean if modern tech people had their way, the web would have never been anything but a bare data API on a blockchain, and no one without at least a bachelors' degree in CS or engineering would even know about it. And oh yeah, you'd need a license to publish anything.
DougMellon 4y ago
> Firefox wasn’t the #2 browser - that’s Safari, mainly because of the captive audience of iPhone and iPad users. But it was the most popular browser that people chose to use. 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.
- briandear 4y ago
  I definitely choose Safari even when on my computer I can use whatever browser I want. It’s a bit presumptuous to assign a reason for Safari popularity without evidence to support people don’t choose it. Not choosing a browser is also a choice. Safari does what they want so they don’t need Firefox.
- jjcon 4y ago
  Also wouldn't that still be chrome? Even though chrome comes preinstalled in some circumstances, the number of people that choose to use it is certainly far higher than the number of people that choose to use firefox. Not to mention that firefox is virtually in a tie with 5 other no-name browsers.
betwixthewires 4y ago
I personally would love a "document web" and an "application web." I've thought of this before independently and talked about it to some people, I think the author is right, the idea of one client application for everything internet related is a core source for the problems we face with the web. 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?
- enobrev 4y ago
  Sounds like more of an indexing problem than anything else. Add a no-js switch to our search engines and you can read all the plain text your internal organs can handle. I tend to like today's web (a bit too corporate for my taste, but I like the potential for variety). But there's no reason the modern web can't look like the old web with the right filters.
  - betwixthewires 4y ago
    It's not just about finding just text to read, it's about finding the documents you want to read and not having to run arbitrary application code to read it.
- fennecs 4y ago
  Why does it have to be so siloed? What if I want documents with a slight bit of inactivity? Why must I go through two different protocols? What if I want to read a paper next to the Juyter notebook that made it? I think it should be the clients job to take whatever slice of a richer universe it wants. This also stops duplication of effort, why maintain separate protocols and clients etc. It’s just a search issue, there are plenty of text websites out there. Protocols like Gemini I think are a waste of time.
afavour 4y ago
In theory I love the idea of a clean start for the web. I agree with the idea of a separation between "document web" and "application web". The problem, though, is that if we were to do away with the web today and invent a replacement I am entirely convinced it would be utterly corrupted by corporate interests. 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.
- dgb23 4y ago
  I feel the same way and share the same concerns. However people have already experienced the open, free web. I don’t think you can take that away anymore.
  - aendruk 4y ago
    It just takes a generation. We’re already on our way there.
bawolff 4y ago
I think the post misunderstands the situation. 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.
- bruce511 4y ago
  I agree. There have been numerous posts along these lines which seem to misunderstand the issue. The post hypothesis is that [something is wrong with the Web] because [browser functionality]. But it's not browser functionality that is the issue here, it's the site author. The premise of the problem is wrong, thus the proposed solution makes no sense, and it will fail. This is easy to demonstrate. Install a second browser. Turn off JavaScript completely. Disable cookies completely. You now have your minimal document viewer. Done. No need for a new protocol, no need to create anything. Now feel free to view all your static-site destinations in this. It'll be rocking fast. Then use your regular browser for everything else. I suspect you'll find that the browser is not the problem. The problem is that the sites you want to visit use JavaScript. You'll discover that your alternate browser is basically not used. Oh and that the sites it can use are equally fast in your main browser. The browser is not slow. Sites _choose_ to be slow as the cost of other things they want (mostly advertising). Any site you think is slow in your browser would not be in your other Web. Do new developers choose inappropriate tools to build simple stuff? Yes of course. Do they go with what they know best, yes of course. Do most senior developers do the same thing? Of course yes. Is the solution a new protocol and a new browser? I fail to see how this would change anything.
- CM30 4y ago
  This times a hundred. It's not that the complexity is the reason, it's simply the audience changing, whether it's the people creating the work or the people consuming it. Look at any online content platform like Medium or Quora or Clubhouse. Quality starts off high, but plummets as more people start finding/using the platform and more businesses see it as a way to make money. Or any entertainment medium. It's not unique to the web, film, television and video games all went a through a similar evolution. People miss the old days, without realising that those days only happened because no one saw the monetary potential in a medium, and the few people with a deep interest in the field (and enough resources to work for free) created stuff as a hobby.
danaugrs 4y ago
We only need an application web. A blog post can be just a markdown file. Want to read it? Use a markdown viewer (from the application web). Want to build a more complex experience? Build an application. You can hardcode/bake the content into it (like we do today). 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/ https://flame.run/ Let's take the good parts of the current web and build a new foundation.
- zzo38computer 4y ago
  > A blog post can be just a markdown file. Want to read it? Use a markdown viewer (from the application web). I had a idea that is a bit similar, which is a Interpreter header; if the MIME type is not understood by the client software, it can download an interpreter (i.e. a polyfill) (written in HTML or WebAssembly, although your own language might also be a possible alternative); if the client software does understand the format (or the end user already has their own implementation installed, possibly one that they wrote by themself), then it will use that one instead. > You can hardcode/bake the content into it (like we do today). While you can, it may make sense to be a separate block so that you can also use the data separately. > 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. That is a interesting idea, and could work (although making the URL longer, probably). Although it may be useful to add additional arguments too, like command-line arguments/switches (so an implementation could be launched by command-line arguments, too). This would easily allow an end user to substitute their own application implementation too (by changing the "application" part of the URL), which is also an advantage, and can have a rewrite system to do their own. If it has a hash then you could also cache the application file if wanted (and if you do not have a working internet connection, even to operate on local files that the user gives permission to access), in addition to overriding it with your own implementation, too. > In fact I've started exploring what that language could look like: https://flame.run/ https://flame.run/ I like this idea and a few days ago had started to make up the design of something called "VM3" (the name might or might not change in future), which has some similar goals and ideas. However, there are many differences too. VM3 is a binary format (designed to be suitable for both interpreter and for JIT, an static analysis; e.g. there is no way to treat a number from a general register as a return address or vice versa, other than using a static lookup table which is specifically designated as containing program addresses), and all I/O (including the equivalent of JavaScript's Date and Math.random) must be done using extensions. Extensions must be statically declared (cannot be dynamically declared), and an implementation must allow the end user to manage and override them too; polyfills (both included and installed separately) are also possible, too. VM3 can be used with any protocols (HTTP(S), Gemini, IPFS, etc) and any storage media (CD, DVD, etc). (VM3 is also not limited to a specific kind of user interface; you can have command-line, GUI, pipes, etc.) Someone else also had wrote some ideas about TerseNet. Some ideas of VM3 are similar, and the capabilities of TerseNet could be implemented as a subset of VM3. Multiple implementation types are possible, and possibility of static text, and applications that are only lauched by the user, also has with TerseNet and VM3. However, unlike Flame which it seem your idea to combine effectively HTML+CSS+JS together, TerseNet and VM3 do something a bit different: parts of HTML (the documentation format) are one format, and other parts of HTML+CSS+JS are the other format; they can easily be separated and work independently.
pkdpic 4y ago
I don't know if I really feel like there's anything wrong with the web. Sure its harder to make slick looking needlessly infinitely scalable socially addictive platforms, but nothing has undermined the ease of writing an html page. And its inarguably easier to find free and excellent resources for learning to develop fir the web. The problem I feel is a blocker for active participation of average citizens is the difficulty of starting / maintaining your own server. Domain name registrars and hosting services are idiotically opaque and difficult to use without giving in to ridiculous paywalls. Even Tim BL admits the domain registrar system was hugely flawed from the start in Weaving the Web. Im just pissed cause I was messing with cname and a records all day...
recursivedoubts 4y ago
What we need is for HTML to get going as a hypermedia again, to make the hypermedia architecture viable for a larger set of web applications. It's been stalled at anchors and forms (with only GET and POST!) for decades now. It's astounding how much we got built with just that. I'm trying to show where it could go with htmx: https://htmx.org https://htmx.org 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.
- pphysch 4y ago
  HTMX is fantastic. Today I built a proof of concept in Django+HTMX+D3.js. Fully reactive, interactive, HTML-first widgets with no npm nor "build" stage. Do anything with good ole HTML templates and just HTMX and D3!
  - tachyon6 4y ago
    I’d love to see the demo! I’m in the process of building something similar
- acabal 4y ago
  I've always been shocked that HTML forms only support GET and POST and there's zero interest in supporting more HTTP methods in forms even in 2022. If forms supported the whole range of HTTP methods we could have a user facing web that's identical to a REST API, with different Accept and Content-type headers. Imagine how much development time we could save if forms supported DELETE and PUT!
  - recursivedoubts 4y ago
    it's incredible that we got WebGL, Web Assembly and a million other things that are neat, but not really crucial to a proper hypermedia implementation, but they can't give us DELETE, PUT and PATCH in HTML, even though they are sitting there in HTTP just staring us in the face! the irony is that DELETE, PUT and PATCH are used today almost exclusively in non-hypermedia JSON data APIs crazy world!
david-cako 4y ago
Regular ass HTML and CSS works just as well as ever. Application frameworks solve problems that are convincing at hyper-giga Google scale (where an infinite number of participants and data models need to be consolidated) that aren't as important when I am trying to display words, pictures, and video to people across the world. For instance, if you're talking about advanced sharding, granular caches per data-field, or scaling microservices with the load on different parts of your application, then maybe you need something more complicated. 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.
r-w 4y ago
If there is a document web, it needs to have paid subscriptions baked in. Like a 404 page but for those who aren’t paying subscribers, and maybe even a way to show an article preview. 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.
- sli 4y ago
  > Like a 404 page but for those who aren’t paying subscribers, ... We got HTTP 402 and nobody used it because it was never standardized (I guess).
Ecco 4y ago
“One codebase, KHTML, split into WebKit and Blink”. That’s inaccurate. Blink is a fork of WebKit that was itself a fork of KHTML. And actually KHTML was really a super tiny project before WebKit.
e-dt 4y ago
Almost all of the companies with power on the web are invested in continuing with it as it is. Given that, the only way to change it so substantially would be to create some kind of grassroots movement for a new version. That's an uphill battle--how are you going to get ordinary people to care? How are you gonna get the average, urgh, "content creator" to ignore network effects and use your platform? What's the "killer app", especially considering it's meant to have less features than the original web?
cosmiccatnap 4y ago
In a landscape consumed with pushing crypto scams and web3 nonsense it was nice just to see a small blurp about someone explaining basically how I feel. 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.
transfire 4y ago
We need to go back even further. Consider one of the things Markdown makes “easier”… making text italic or bold. Now ask, why do we have to resort to special syntax formats for this? It should be a simple function of the keyboard itself, no more complex then shift (or caps lock). Extend this to superscript, strike-thru, etc. and a good chunk of Markdown just evaporates.
sally1620 4y ago
This kind of initiative could take off. Only if it is backed by a big player. Basically Apple Google and Microsoft. 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
qudat 4y ago
I also had similar thoughts without the eloquence of this article. The one area I disagree with the author is: > 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. I think supporting everything but javascript for the "document browser" would automatically enable a ton of websites and make it easier for creators and consumers to use the tools and languages they already understand. https://erock.lists.sh/browser-monopoly https://erock.lists.sh/browser-monopoly
- zzo38computer 4y ago
  > I think supporting everything but javascript for the "document browser" would automatically enable a ton of websites and make it easier for creators and consumers to use the tools and languages they already understand. There are some merits for that, but I think that is both excessive and deficient at the same time. > https://erock.lists.sh/browser-monopoly https://erock.lists.sh/browser-monopoly I think that these are valid points, which I have some comments relating to. > Support HTML 5, CSS 3, HTTP, TLS You can add other file formats and protocols too, such as Gemini, Gopher, and possibly Markdown too. > Maybe remove website specific styling altogether and instead design a consistent design that optimizes navigation and readability. That is what I think too; even the HTML with no CSS, will be OK. Perhaps let the end user to specify colours, fonts, etc. > Allowing the user to query for information and have that data displayed without full page reloads (AJAX) For data-oriented stuff, you could also have such things like <a rel="data">, you can just get the data and use your own software to display it. > I want a minimal, modern set of browsing tools where I don't have to make any sacrifices between usability and compliance with the standards. Yes, I think so, too. Splitting all of the components separately is one start, I suppose (although it is not good enough by itself) (a C program can then be written to tie them together, and this can be changed as needed, including to add/remove components) (this is like reversing core and extensions the other way, so that e.g. HTML and HTTP are now extensions instead of core). However, half of the standards are I don't want quite compliance and should deliberately implement them in a better way than what they say.
deleted 4y ago
[deleted]
dmje 4y ago
It's strange but as - I suppose "veteran" (sigh) Web guy, I just don't see the problem of building stuff(+) in html, css and maybe a sprinkling of js + PHP or whatever else serverside if you need it. (+) 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...
imiric 4y ago
The problems with the modern web are hardly technical. We have the technology to make it better. 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[1] 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. [1]: https://basicattentiontoken.org/ https://basicattentiontoken.org/
- achenet 4y ago
  ask for donations. Make good work, people will pay to support it. Works for NPR.
viksit 4y ago
The biggest challenge for decentralization is cost - who pays for the machines that run the code, irrespective of what the code is written in. The reason we got centralized was simply who pays to power the chips!
locallost 4y ago
> First, you need a minimal, standardized markup language for sending documents around > 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.
- gjvc 4y ago
  100% agree. This is the reference, for those who are interested -- watch for a few minutes starting at https://www.youtube.com/watch?v=oKg1hTOQXoY&t=1280s https://www.youtube.com/watch?v=oKg1hTOQXoY&t=1280s
gjvc 4y ago
this observation from 1997 always rings true. watch a few minutes starting at https://www.youtube.com/watch?v=oKg1hTOQXoY&t=1280s https://www.youtube.com/watch?v=oKg1hTOQXoY&t=1280s
shmde 4y ago
Aaand internal leaked restricted bug show firefox is testing its frontend to use blink[1] ( developed by google ). I thought abc.xyz which is owned by google was an obnoxious thing to do which meant the internet began (abc) and ended ( xyz ) with google. But now its clear that it really is just them playing god. Really wondering how long till ftc breaks up google. Every fucking engine is now chromium derivative or google made. edit: added leak link. edit 2: Turns out to be fake, confirmed by mozilla employee[2]. Stupid 4chan. [1]https://boards.4channel.org/g/thread/86921913/ https://boards.4channel.org/g/thread/86921913/ [2]https://old.reddit.com/r/firefox/comments/uovcdh/only_a_rumor_so_far_but_theres_this_screenshot/ https://old.reddit.com/r/firefox/comments/uovcdh/only_a_rumo...
- chrismorgan 4y ago
  Citation? (I haven’t heard anything about this, and from what I do know of Firefox I can’t see how anything even vaguely like what I think you’re describing would be technically feasible.)
  - shmde 4y ago
    https://boards.4channel.org/g/thread/86921913/ https://boards.4channel.org/g/thread/86921913/
    - chrismorgan 4y ago
      https://old.reddit.com/r/firefox/comments/uovcdh/only_a_rumor_so_far_but_theres_this_screenshot/ https://old.reddit.com/r/firefox/comments/uovcdh/only_a_rumo...: multiple authenticated sources confirm this to be a fake. Beyond that, some details about the presentation of the page don’t match what you’d expect (covered in the comments), and the terminology in the comment looks quite wrong to me too (it’s a mixture of technically incorrect, suggesting technical unfamiliarity, and overly specific, suggesting technical familiarity).
- account42 4y ago
  > Aaand internal leaked restricted bug show firefox is testing its frontend to use blink At this point, Mozilla clearly saying they are stopping Gecko or Gecko-based Firefox development might best thing that can happen to FF -- that is if it will be enough to get others to band together and finally replace Mozilla with an organization that actually cares about the needs and wants of its users.
seydor 4y ago
I don't know, i want the web to be steered back to basics. The whole SPA thing should not exist, HTML is documents. Instead, native platforms should provide each of the widgets and UIs that the SPAs download in each and every page load. There's already a lot of <input> tags for things like date and such. We should have more native support for all kinds of interactions in touchscreens too. After all they are not that many - after so many years only few kinds of touchscreen interactions have survived 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
timdp 4y ago
Thanks for reposting this, dannyow! I'd been trying to find it forever.
bullen 4y ago
I would say .html, .css and .js and the browser are becoming over-engineered. HTTP and SMTP are fine however. I have stopped coding .html and only use HTTP now from a native OpenGL client written in C.
- zzo38computer 4y ago
  I would agree, although HTTP and SMTP are not the only protocols; in many cases other protocols should do better (such as IRC, SSH, etc). > I have stopped coding .html and only use HTTP now from a native OpenGL client written in C. How is that working? Do you have any further details?
  - bullen 4y ago
    SSH is not a frontend protocol, but I use that for the backend. IRC is replacable with HTTP. It's a 3D MMO: http://talk.binarytask.com/task?id=5959519327505901449 http://talk.binarytask.com/task?id=5959519327505901449
divan 4y ago
/me patiently waiting until Chrome is shipped with Dart VM again, so Flutter apps can run natively in the browser.
bsenftner 4y ago
IMHO, the human race has degraded in maturity in the last 20-30 years, and today we do not have a critical mass of technically adept, intellectually mature and who are also skilled debating communicators capable of making this change without the entire process derailing, and the result being far, far worse than what we have today. 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. Case in point: https://www.cnn.com/2018/06/13/health/falling-iq-scores-study-intl/index.html https://www.cnn.com/2018/06/13/health/falling-iq-scores-stud...
Barrera 4y ago
> We hope that all this innovation is for the user, but often it isn’t. Modern websites seem to be as large, slow, and buggy as they’ve ever been. Our computers are barely getting faster and our internet connection speeds are stagnating (don’t even try to mention 5G). Webpage size growth is outpacing it all. 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?
skadamat 4y ago
Surprised to see HyperCard not mentioned here. https://arstechnica.com/gadgets/2019/05/25-years-of-hypercard-the-missing-link-to-the-web/ https://arstechnica.com/gadgets/2019/05/25-years-of-hypercar... It was a delightful foundation for the document web!
DeathArrow 4y ago
One thing I don't get. We use Web for apps because desktop and mobile apps aren't portable. But why don't we use instead Java or .NET apps, which can be portable? 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.
- krapp 4y ago
  If you want a web only capable of delivering static documents, you may be interested in Geminispace. As far as why we use the web for "apps" (which seems to mean any site with any non-trivial interactivity provided by javascript, as opposed to any site emulating the function of a native application, which there are few of,) we do so simply for the reason that the web as a platform already exists, and is ubiquitous, and provides a single development distribution model for text and interactivity, and that is more convenient than forcing text to be in one place and everything else to run in separate application spaces. Running code on the web was conceived of as a possibility from the beginning, the premise that it was only ever supposed to support static documents, but then got 'corrupted' into supporting "applications," is kind of a modern retrofiction. Also, the premise that only static documents contain information, whereas applications don't, isn't correct. The vast majority of what are considered "web apps" are, functionally, just dynamic multimedia documents. For everything else - actual web applications - WASM will probably be the solution.
account-5 4y ago
> For folks who just want to create a web page, who don’t want to enter an industry, there’s a baffling array of techniques, but all the simplest, probably-best ones are stigmatized. It’s easier to stumble into building your resume in React with GraphQL than it is to type some HTML in Notepad. This can't be understated. I'm a web-dev noob. I'm doing simple stuff, HTML/CSS/JavaScript is what I've decided to learn after months of confusion about this or that framework which at the start I was very confused about until I found out they are all just JavaScript abstraction.
zzo38computer 4y ago
> It’s easier to stumble into building your resume in React with GraphQL than it is to type some HTML in Notepad. It is untrue. You can write a plain HTML (even without CSS) and it will work OK. > Webpage size growth is outpacing it all. It is true, unfortunately. They waste too much space by adding too much extra pictures, CSS, JavaScripts, videos, advertising, etc. You should not need all of that stuff. > 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. I do not use Facebook, but I can comment about the others. There is NNTP, too. Wikipedia (and MediaWiki in general; not only Wikipedia) uses a lot of JavaScripts and CSS too; you can add your own, but removing the existing ones and replacing by your own will be difficult. If you want to replace the audio/video player with your own, can you do it? What is needing is making actual proper HTML, or EncapsulatedHyperEncyclopedia format, perhaps. > 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.)

290 points by dannyow 4y ago

b1n 4y ago

This is an idea whose time has come.

chris123 4y ago
The road to hell is paved with good intentions and do-gooders.

deleted 4y ago

[deleted]

5350-uiop-1130 4y ago

Just stop building your web "apps" on the client side. Why should I pay to save on your server costs. An app is an app, a website is a website, don't try to make them the same thing always.

skybrian 4y ago

The web is far too big to invent all at once. Evolution is how it's going to go from now on. Good ideas will start out in niches. 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.

0xbadcafebee 4y ago

Do we really want to continue having "a web" ? Remember, "the web" was never designed for what we do with it today. If you're thinking of overhauling "the web", I think it makes sense to start from first principles, and build something that meets today's needs with the least amount of unnecessary bullshit. 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.

deleted 4y ago
[deleted]
rektide 4y ago
What feels unique about the web, that nothing else remotely resembles that makes it so much more compelling to me versus everything which came before, is urls. The web is a network of online resources. There's HTML, an ok, fairly adaptable hyper-media markup- and CSS, and scripts, all fair or better- but the premise turns everything else we do in computing on it's head: servers send us resources, and we have a (imo pretty great) engine to render & execute our hypermedia. I see endless torrents of anti-web attitude, from people who want more content-centric systems, from people who want applications. But almost never can the critics identify & mark out what makes the web better, different, & so flexible as to have arisen into all-pervading ubiquitous. By all means, consider first principles. I think you all have a lot of very important & enabling concepts you'll need to recreate along the way. The web's idea of urls & resources is one I think we'll have a hard time replacing.
- zzo38computer 4y ago
  While there are some good ideas, there are also many bad ones. (URLs are one good idea.) It could be designed better. Perhaps I can mention this quotation (which wasn't about HTML, although some of the bad things happen with HTML for similar reasons): The sad fact of the matter is that people play politics with standards to gain commercial advantage, and the result is that end users suffer the consequences. This is the case with character encoding for computer systems, and it is even more the case with HDTV.
  - rektide 4y ago
    It mostly works pretty great. It's immensely popular to hate on.
EddieDante 4y ago
> Do we really want to continue having "a web"? Speaking only for myself, I'm not at all invested in having a website. Yes, I want a publicly accessible site of my own on the internet with which to share documents, and I currently do so over HTTP, but I would equally happy to share them over Gopher or even anonymous FTP. However, I'd rather pay NearlyFreeSpeech.net for hosting than run my own VPS or self-host on a machine in my basement because I'm lazy, so I'm stuck with HTTP because they explicitly don't support anonymous FTP (and by implication don't support Gopher or Gemini).

rektide 4y ago

(2020). Editorialized title ("A Clean Start for the Web"). Previously discussed in: https://news.ycombinator.com/item?id=24255541 https://news.ycombinator.com/item?id=24255541 (117 points, 21 months ago, 90 comments)

dang 4y ago
Thanks! Macroexpanded: A Clean Start for the Web - https://news.ycombinator.com/item?id=24255541 https://news.ycombinator.com/item?id=24255541 - Aug 2020 (90 comments) A Clean Start for the Web - https://news.ycombinator.com/item?id=24250252 https://news.ycombinator.com/item?id=24250252 - Aug 2020 (1 comment) A Clean Start for the Web - https://news.ycombinator.com/item?id=24247362 https://news.ycombinator.com/item?id=24247362 - Aug 2020 (3 comments)

jonny_eh 4y ago

The digital equivalent of "we screwed up Earth, let's go to Mars and screw things up all over again!"

egypturnash 4y ago

"But the early web wasn’t fun in many conventional ways - you couldn’t quite create art there, or use it as much more than a way of sharing documents." 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.

enobrev 4y ago
It's a beautiful thing. I remember the days you speak of. I also remember the leaps and bounds people took to bend myspace to their will. All for expression. It's been a beautiful and very human journey I'm not sure we would have gotten where we are now without those limitations for people to conquer. There's nothing in http that requires a browser. We could have released multiple app platforms by now. But there's a magic in html, css, and js that is taken completely for granted. I remain a fan. ...Edit to add that we have added these platforms. And they can't come close to what we have on the web. Roku, Apple TV, Nvidia Shield. These are application platforms. And they're ok for what they are. Android and IOS are the most successful connected platforms we have, and they're impressive, but I still spend more time in my browser than anything else on my mobile device.

pronlover723 4y ago

I think the web is mostly good the way it is and I don't want to see it re-invented. In fact, I hate Flutter because it's not "webby". It renderers all content and controls using Canvas which means all there is on the page is pixels which means no accessibility since there is no standard structure (the DOM) to dig through to find the content. 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.

krapp 4y ago
I have yet to see a suggestion to "reinvent" the web that expands on publisher or end-user capabilities, rather than taking them away. The end user doesn't want Geminispace, they don't hate that web publishers get to control layout and design, or that sites can be more complex than even the early web allowed. They don't want to write their own clients or stylesheets, they don't want the web to only be strictly static documents, with "apps" quarantined elsewhere. They don't want a different markup language. They don't want to destroy social media and force services not to use algorithmic feeds or discovery because it's "mind control." They don't want to kill all advertising and commerce on the web in the belief that content creators should be forced to work for love instead of money. I mean if modern tech people had their way, the web would have never been anything but a bare data API on a blockchain, and no one without at least a bachelors' degree in CS or engineering would even know about it. And oh yeah, you'd need a license to publish anything.

DougMellon 4y ago

> Firefox wasn’t the #2 browser - that’s Safari, mainly because of the captive audience of iPhone and iPad users. But it was the most popular browser that people chose to use. 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.

briandear 4y ago
I definitely choose Safari even when on my computer I can use whatever browser I want. It’s a bit presumptuous to assign a reason for Safari popularity without evidence to support people don’t choose it. Not choosing a browser is also a choice. Safari does what they want so they don’t need Firefox.
jjcon 4y ago
Also wouldn't that still be chrome? Even though chrome comes preinstalled in some circumstances, the number of people that choose to use it is certainly far higher than the number of people that choose to use firefox. Not to mention that firefox is virtually in a tie with 5 other no-name browsers.

betwixthewires 4y ago

I personally would love a "document web" and an "application web." I've thought of this before independently and talked about it to some people, I think the author is right, the idea of one client application for everything internet related is a core source for the problems we face with the web. 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?

enobrev 4y ago
Sounds like more of an indexing problem than anything else. Add a no-js switch to our search engines and you can read all the plain text your internal organs can handle. I tend to like today's web (a bit too corporate for my taste, but I like the potential for variety). But there's no reason the modern web can't look like the old web with the right filters.
- betwixthewires 4y ago
  It's not just about finding just text to read, it's about finding the documents you want to read and not having to run arbitrary application code to read it.
fennecs 4y ago
Why does it have to be so siloed? What if I want documents with a slight bit of inactivity? Why must I go through two different protocols? What if I want to read a paper next to the Juyter notebook that made it? I think it should be the clients job to take whatever slice of a richer universe it wants. This also stops duplication of effort, why maintain separate protocols and clients etc. It’s just a search issue, there are plenty of text websites out there. Protocols like Gemini I think are a waste of time.

afavour 4y ago

In theory I love the idea of a clean start for the web. I agree with the idea of a separation between "document web" and "application web". The problem, though, is that if we were to do away with the web today and invent a replacement I am entirely convinced it would be utterly corrupted by corporate interests. 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.

dgb23 4y ago
I feel the same way and share the same concerns. However people have already experienced the open, free web. I don’t think you can take that away anymore.
- aendruk 4y ago
  It just takes a generation. We’re already on our way there.

bawolff 4y ago

I think the post misunderstands the situation. 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.

bruce511 4y ago
I agree. There have been numerous posts along these lines which seem to misunderstand the issue. The post hypothesis is that [something is wrong with the Web] because [browser functionality]. But it's not browser functionality that is the issue here, it's the site author. The premise of the problem is wrong, thus the proposed solution makes no sense, and it will fail. This is easy to demonstrate. Install a second browser. Turn off JavaScript completely. Disable cookies completely. You now have your minimal document viewer. Done. No need for a new protocol, no need to create anything. Now feel free to view all your static-site destinations in this. It'll be rocking fast. Then use your regular browser for everything else. I suspect you'll find that the browser is not the problem. The problem is that the sites you want to visit use JavaScript. You'll discover that your alternate browser is basically not used. Oh and that the sites it can use are equally fast in your main browser. The browser is not slow. Sites _choose_ to be slow as the cost of other things they want (mostly advertising). Any site you think is slow in your browser would not be in your other Web. Do new developers choose inappropriate tools to build simple stuff? Yes of course. Do they go with what they know best, yes of course. Do most senior developers do the same thing? Of course yes. Is the solution a new protocol and a new browser? I fail to see how this would change anything.
CM30 4y ago
This times a hundred. It's not that the complexity is the reason, it's simply the audience changing, whether it's the people creating the work or the people consuming it. Look at any online content platform like Medium or Quora or Clubhouse. Quality starts off high, but plummets as more people start finding/using the platform and more businesses see it as a way to make money. Or any entertainment medium. It's not unique to the web, film, television and video games all went a through a similar evolution. People miss the old days, without realising that those days only happened because no one saw the monetary potential in a medium, and the few people with a deep interest in the field (and enough resources to work for free) created stuff as a hobby.

danaugrs 4y ago

We only need an application web. A blog post can be just a markdown file. Want to read it? Use a markdown viewer (from the application web). Want to build a more complex experience? Build an application. You can hardcode/bake the content into it (like we do today). 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/ https://flame.run/ Let's take the good parts of the current web and build a new foundation.

zzo38computer 4y ago
> A blog post can be just a markdown file. Want to read it? Use a markdown viewer (from the application web). I had a idea that is a bit similar, which is a Interpreter header; if the MIME type is not understood by the client software, it can download an interpreter (i.e. a polyfill) (written in HTML or WebAssembly, although your own language might also be a possible alternative); if the client software does understand the format (or the end user already has their own implementation installed, possibly one that they wrote by themself), then it will use that one instead. > You can hardcode/bake the content into it (like we do today). While you can, it may make sense to be a separate block so that you can also use the data separately. > 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. That is a interesting idea, and could work (although making the URL longer, probably). Although it may be useful to add additional arguments too, like command-line arguments/switches (so an implementation could be launched by command-line arguments, too). This would easily allow an end user to substitute their own application implementation too (by changing the "application" part of the URL), which is also an advantage, and can have a rewrite system to do their own. If it has a hash then you could also cache the application file if wanted (and if you do not have a working internet connection, even to operate on local files that the user gives permission to access), in addition to overriding it with your own implementation, too. > In fact I've started exploring what that language could look like: https://flame.run/ https://flame.run/ I like this idea and a few days ago had started to make up the design of something called "VM3" (the name might or might not change in future), which has some similar goals and ideas. However, there are many differences too. VM3 is a binary format (designed to be suitable for both interpreter and for JIT, an static analysis; e.g. there is no way to treat a number from a general register as a return address or vice versa, other than using a static lookup table which is specifically designated as containing program addresses), and all I/O (including the equivalent of JavaScript's Date and Math.random) must be done using extensions. Extensions must be statically declared (cannot be dynamically declared), and an implementation must allow the end user to manage and override them too; polyfills (both included and installed separately) are also possible, too. VM3 can be used with any protocols (HTTP(S), Gemini, IPFS, etc) and any storage media (CD, DVD, etc). (VM3 is also not limited to a specific kind of user interface; you can have command-line, GUI, pipes, etc.) Someone else also had wrote some ideas about TerseNet. Some ideas of VM3 are similar, and the capabilities of TerseNet could be implemented as a subset of VM3. Multiple implementation types are possible, and possibility of static text, and applications that are only lauched by the user, also has with TerseNet and VM3. However, unlike Flame which it seem your idea to combine effectively HTML+CSS+JS together, TerseNet and VM3 do something a bit different: parts of HTML (the documentation format) are one format, and other parts of HTML+CSS+JS are the other format; they can easily be separated and work independently.

pkdpic 4y ago

I don't know if I really feel like there's anything wrong with the web. Sure its harder to make slick looking needlessly infinitely scalable socially addictive platforms, but nothing has undermined the ease of writing an html page. And its inarguably easier to find free and excellent resources for learning to develop fir the web. The problem I feel is a blocker for active participation of average citizens is the difficulty of starting / maintaining your own server. Domain name registrars and hosting services are idiotically opaque and difficult to use without giving in to ridiculous paywalls. Even Tim BL admits the domain registrar system was hugely flawed from the start in Weaving the Web. Im just pissed cause I was messing with cname and a records all day...

recursivedoubts 4y ago

What we need is for HTML to get going as a hypermedia again, to make the hypermedia architecture viable for a larger set of web applications. It's been stalled at anchors and forms (with only GET and POST!) for decades now. It's astounding how much we got built with just that. I'm trying to show where it could go with htmx: https://htmx.org https://htmx.org 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.

pphysch 4y ago
HTMX is fantastic. Today I built a proof of concept in Django+HTMX+D3.js. Fully reactive, interactive, HTML-first widgets with no npm nor "build" stage. Do anything with good ole HTML templates and just HTMX and D3!
- tachyon6 4y ago
  I’d love to see the demo! I’m in the process of building something similar
acabal 4y ago
I've always been shocked that HTML forms only support GET and POST and there's zero interest in supporting more HTTP methods in forms even in 2022. If forms supported the whole range of HTTP methods we could have a user facing web that's identical to a REST API, with different Accept and Content-type headers. Imagine how much development time we could save if forms supported DELETE and PUT!
- recursivedoubts 4y ago
  it's incredible that we got WebGL, Web Assembly and a million other things that are neat, but not really crucial to a proper hypermedia implementation, but they can't give us DELETE, PUT and PATCH in HTML, even though they are sitting there in HTTP just staring us in the face! the irony is that DELETE, PUT and PATCH are used today almost exclusively in non-hypermedia JSON data APIs crazy world!

david-cako 4y ago

Regular ass HTML and CSS works just as well as ever. Application frameworks solve problems that are convincing at hyper-giga Google scale (where an infinite number of participants and data models need to be consolidated) that aren't as important when I am trying to display words, pictures, and video to people across the world. For instance, if you're talking about advanced sharding, granular caches per data-field, or scaling microservices with the load on different parts of your application, then maybe you need something more complicated. 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.

r-w 4y ago

If there is a document web, it needs to have paid subscriptions baked in. Like a 404 page but for those who aren’t paying subscribers, and maybe even a way to show an article preview. 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.

sli 4y ago
> Like a 404 page but for those who aren’t paying subscribers, ... We got HTTP 402 and nobody used it because it was never standardized (I guess).

Ecco 4y ago

“One codebase, KHTML, split into WebKit and Blink”. That’s inaccurate. Blink is a fork of WebKit that was itself a fork of KHTML. And actually KHTML was really a super tiny project before WebKit.

e-dt 4y ago

Almost all of the companies with power on the web are invested in continuing with it as it is. Given that, the only way to change it so substantially would be to create some kind of grassroots movement for a new version. That's an uphill battle--how are you going to get ordinary people to care? How are you gonna get the average, urgh, "content creator" to ignore network effects and use your platform? What's the "killer app", especially considering it's meant to have less features than the original web?

cosmiccatnap 4y ago

In a landscape consumed with pushing crypto scams and web3 nonsense it was nice just to see a small blurp about someone explaining basically how I feel. 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.

transfire 4y ago

We need to go back even further. Consider one of the things Markdown makes “easier”… making text italic or bold. Now ask, why do we have to resort to special syntax formats for this? It should be a simple function of the keyboard itself, no more complex then shift (or caps lock). Extend this to superscript, strike-thru, etc. and a good chunk of Markdown just evaporates.

sally1620 4y ago

This kind of initiative could take off. Only if it is backed by a big player. Basically Apple Google and Microsoft. 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

qudat 4y ago

I also had similar thoughts without the eloquence of this article. The one area I disagree with the author is: > 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. I think supporting everything but javascript for the "document browser" would automatically enable a ton of websites and make it easier for creators and consumers to use the tools and languages they already understand. https://erock.lists.sh/browser-monopoly https://erock.lists.sh/browser-monopoly

zzo38computer 4y ago
> I think supporting everything but javascript for the "document browser" would automatically enable a ton of websites and make it easier for creators and consumers to use the tools and languages they already understand. There are some merits for that, but I think that is both excessive and deficient at the same time. > https://erock.lists.sh/browser-monopoly https://erock.lists.sh/browser-monopoly I think that these are valid points, which I have some comments relating to. > Support HTML 5, CSS 3, HTTP, TLS You can add other file formats and protocols too, such as Gemini, Gopher, and possibly Markdown too. > Maybe remove website specific styling altogether and instead design a consistent design that optimizes navigation and readability. That is what I think too; even the HTML with no CSS, will be OK. Perhaps let the end user to specify colours, fonts, etc. > Allowing the user to query for information and have that data displayed without full page reloads (AJAX) For data-oriented stuff, you could also have such things like <a rel="data">, you can just get the data and use your own software to display it. > I want a minimal, modern set of browsing tools where I don't have to make any sacrifices between usability and compliance with the standards. Yes, I think so, too. Splitting all of the components separately is one start, I suppose (although it is not good enough by itself) (a C program can then be written to tie them together, and this can be changed as needed, including to add/remove components) (this is like reversing core and extensions the other way, so that e.g. HTML and HTTP are now extensions instead of core). However, half of the standards are I don't want quite compliance and should deliberately implement them in a better way than what they say.

deleted 4y ago

[deleted]

dmje 4y ago

It's strange but as - I suppose "veteran" (sigh) Web guy, I just don't see the problem of building stuff(+) in html, css and maybe a sprinkling of js + PHP or whatever else serverside if you need it. (+) 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...

imiric 4y ago

The problems with the modern web are hardly technical. We have the technology to make it better. 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[1] 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. [1]: https://basicattentiontoken.org/ https://basicattentiontoken.org/

achenet 4y ago
ask for donations. Make good work, people will pay to support it. Works for NPR.

viksit 4y ago

The biggest challenge for decentralization is cost - who pays for the machines that run the code, irrespective of what the code is written in. The reason we got centralized was simply who pays to power the chips!

locallost 4y ago

> First, you need a minimal, standardized markup language for sending documents around > 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.

gjvc 4y ago
100% agree. This is the reference, for those who are interested -- watch for a few minutes starting at https://www.youtube.com/watch?v=oKg1hTOQXoY&t=1280s https://www.youtube.com/watch?v=oKg1hTOQXoY&t=1280s

gjvc 4y ago

this observation from 1997 always rings true. watch a few minutes starting at https://www.youtube.com/watch?v=oKg1hTOQXoY&t=1280s https://www.youtube.com/watch?v=oKg1hTOQXoY&t=1280s

shmde 4y ago

Aaand internal leaked restricted bug show firefox is testing its frontend to use blink[1] ( developed by google ). I thought abc.xyz which is owned by google was an obnoxious thing to do which meant the internet began (abc) and ended ( xyz ) with google. But now its clear that it really is just them playing god. Really wondering how long till ftc breaks up google. Every fucking engine is now chromium derivative or google made. edit: added leak link. edit 2: Turns out to be fake, confirmed by mozilla employee[2]. Stupid 4chan. [1]https://boards.4channel.org/g/thread/86921913/ https://boards.4channel.org/g/thread/86921913/ [2]https://old.reddit.com/r/firefox/comments/uovcdh/only_a_rumor_so_far_but_theres_this_screenshot/ https://old.reddit.com/r/firefox/comments/uovcdh/only_a_rumo...

chrismorgan 4y ago
Citation? (I haven’t heard anything about this, and from what I do know of Firefox I can’t see how anything even vaguely like what I think you’re describing would be technically feasible.)
- shmde 4y ago
  https://boards.4channel.org/g/thread/86921913/ https://boards.4channel.org/g/thread/86921913/
  - chrismorgan 4y ago
    https://old.reddit.com/r/firefox/comments/uovcdh/only_a_rumor_so_far_but_theres_this_screenshot/ https://old.reddit.com/r/firefox/comments/uovcdh/only_a_rumo...: multiple authenticated sources confirm this to be a fake. Beyond that, some details about the presentation of the page don’t match what you’d expect (covered in the comments), and the terminology in the comment looks quite wrong to me too (it’s a mixture of technically incorrect, suggesting technical unfamiliarity, and overly specific, suggesting technical familiarity).
account42 4y ago
> Aaand internal leaked restricted bug show firefox is testing its frontend to use blink At this point, Mozilla clearly saying they are stopping Gecko or Gecko-based Firefox development might best thing that can happen to FF -- that is if it will be enough to get others to band together and finally replace Mozilla with an organization that actually cares about the needs and wants of its users.

seydor 4y ago

I don't know, i want the web to be steered back to basics. The whole SPA thing should not exist, HTML is documents. Instead, native platforms should provide each of the widgets and UIs that the SPAs download in each and every page load. There's already a lot of <input> tags for things like date and such. We should have more native support for all kinds of interactions in touchscreens too. After all they are not that many - after so many years only few kinds of touchscreen interactions have survived 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

timdp 4y ago

Thanks for reposting this, dannyow! I'd been trying to find it forever.

bullen 4y ago

I would say .html, .css and .js and the browser are becoming over-engineered. HTTP and SMTP are fine however. I have stopped coding .html and only use HTTP now from a native OpenGL client written in C.

zzo38computer 4y ago
I would agree, although HTTP and SMTP are not the only protocols; in many cases other protocols should do better (such as IRC, SSH, etc). > I have stopped coding .html and only use HTTP now from a native OpenGL client written in C. How is that working? Do you have any further details?
- bullen 4y ago
  SSH is not a frontend protocol, but I use that for the backend. IRC is replacable with HTTP. It's a 3D MMO: http://talk.binarytask.com/task?id=5959519327505901449 http://talk.binarytask.com/task?id=5959519327505901449

divan 4y ago

/me patiently waiting until Chrome is shipped with Dart VM again, so Flutter apps can run natively in the browser.

bsenftner 4y ago

IMHO, the human race has degraded in maturity in the last 20-30 years, and today we do not have a critical mass of technically adept, intellectually mature and who are also skilled debating communicators capable of making this change without the entire process derailing, and the result being far, far worse than what we have today. 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. Case in point: https://www.cnn.com/2018/06/13/health/falling-iq-scores-study-intl/index.html https://www.cnn.com/2018/06/13/health/falling-iq-scores-stud...

Barrera 4y ago

> We hope that all this innovation is for the user, but often it isn’t. Modern websites seem to be as large, slow, and buggy as they’ve ever been. Our computers are barely getting faster and our internet connection speeds are stagnating (don’t even try to mention 5G). Webpage size growth is outpacing it all. 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?

skadamat 4y ago

Surprised to see HyperCard not mentioned here. https://arstechnica.com/gadgets/2019/05/25-years-of-hypercard-the-missing-link-to-the-web/ https://arstechnica.com/gadgets/2019/05/25-years-of-hypercar... It was a delightful foundation for the document web!

DeathArrow 4y ago

One thing I don't get. We use Web for apps because desktop and mobile apps aren't portable. But why don't we use instead Java or .NET apps, which can be portable? 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.

krapp 4y ago
If you want a web only capable of delivering static documents, you may be interested in Geminispace. As far as why we use the web for "apps" (which seems to mean any site with any non-trivial interactivity provided by javascript, as opposed to any site emulating the function of a native application, which there are few of,) we do so simply for the reason that the web as a platform already exists, and is ubiquitous, and provides a single development distribution model for text and interactivity, and that is more convenient than forcing text to be in one place and everything else to run in separate application spaces. Running code on the web was conceived of as a possibility from the beginning, the premise that it was only ever supposed to support static documents, but then got 'corrupted' into supporting "applications," is kind of a modern retrofiction. Also, the premise that only static documents contain information, whereas applications don't, isn't correct. The vast majority of what are considered "web apps" are, functionally, just dynamic multimedia documents. For everything else - actual web applications - WASM will probably be the solution.

account-5 4y ago

> For folks who just want to create a web page, who don’t want to enter an industry, there’s a baffling array of techniques, but all the simplest, probably-best ones are stigmatized. It’s easier to stumble into building your resume in React with GraphQL than it is to type some HTML in Notepad. This can't be understated. I'm a web-dev noob. I'm doing simple stuff, HTML/CSS/JavaScript is what I've decided to learn after months of confusion about this or that framework which at the start I was very confused about until I found out they are all just JavaScript abstraction.

zzo38computer 4y ago

> It’s easier to stumble into building your resume in React with GraphQL than it is to type some HTML in Notepad. It is untrue. You can write a plain HTML (even without CSS) and it will work OK. > Webpage size growth is outpacing it all. It is true, unfortunately. They waste too much space by adding too much extra pictures, CSS, JavaScripts, videos, advertising, etc. You should not need all of that stuff. > 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. I do not use Facebook, but I can comment about the others. There is NNTP, too. Wikipedia (and MediaWiki in general; not only Wikipedia) uses a lot of JavaScripts and CSS too; you can add your own, but removing the existing ones and replacing by your own will be difficult. If you want to replace the audio/video player with your own, can you do it? What is needing is making actual proper HTML, or EncapsulatedHyperEncyclopedia format, perhaps. > 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.)