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.
The problem with "one client to rule them all" is a massive lost of consistency, speed/responsiveness, and usability when it comes to documents. On the web, documents can come in anything ranging from the form of a tiny text file to a gargantuan "app" that weighs tens of megabytes and spins up your laptop's fans to render. It also means that the browser isn't nearly as smart as it could be because it has to be a general purpose jack of all trades.
A dedicated document browser would likely almost always blazing fast, regardless of the machine it was run on and the network over which the documents were transferred over. It could have features that would make no sense in a web browser but greatly enhance the experience of reading and navigation. It could reasonably cache nearly everything the user visits (since it's practically all read-only and small) to reduce server load and increase speed. In a nutshell, it could be far better at specifically working with documents than a web browser ever could, even with a laundry list of extensions installed.
Additionally, it would actually be possible to write brand new competing document browsers due to the vastly more simple specification, which is something the web will probably never have again.
I find this compelling, but the lines feel blurry to me. For example, take Hacker News. When I read hacker news, it's both static and simple. But, if I want to make a comment, suddenly I need authentication and a text box. So, does all of Hacker News have to be in an application web to support comments? Do I have to use two different applications to read or submit comments?
Next level of complexity might be form entry. Say I want to buy tickets for a conference, and need to submit my credit card information, phone number, address, etc. We already have authorization from HN, but are the credit card and phone number boxes just plain text boxes? No validation or interactive feedback until I POST? When I enter my address, do I get a map of where that is so that I don't confuse N xx-th St NYC with xx-th St NYC, one of which is in Brooklyn and one of which is in Manhattan?
On the flip side in the application web, when I'm doing my banking. If you go all the way to pixels, how does my accessibility reader handle it?
The problem with one client is that the client is made by a corporation whose interests are not aligned well with the interests of the users and of other companies.
One company owning the Web and practically dictating standards, what users can do or not do on web, it's pretty damn bad.
> What if I want documents with a slight bit of inactivity?
Then you use Adobe Flash. See, we used to have a decent technology for when you want "a document with a slight bit of interactivity". It worked very well for this exact purpose. More than 10 years later, browsers' native capabilities, that are supposed to be a replacement for what Flash offered, have still not quite caught up. Moreover, Flash defined a clear boundary between the document and the application parts.
Did the particular (Adobe's proprietary) implementation of Flash player suck? Yes, sure. Could this have been done better? Yes, sure. Is it possible to reimplement a Flash player from scratch within a reasonable timeframe with a small team of developers? Yes, sure, Ruffle[1] is a thing, and it's being actively developed.
I miss Flash. I hope it makes a comeback eventually.
This sort of "wouldnt it be great to have some other thing, so we can murder the rest of the web platform" is so grotesque to me, just repugnant & vile & cruel.
Flash is a comedically shit technology. There's a couple animation capabilities it had that were nice & simple & people adore it endlessly for that. But Flash hated users, gave them nothing, no power (alike a native app) & was a big proprietary anti-hypermedia ball of jank, and it had the most trashfire craptastic lack of accessibility one could ever imagine.
This desire to keep hypermedia down, to create hard walls between different purposes of apps... it feels poisonous & misguided. There is too much of the web today thay does abuse client side code too much. But frankly it rarely affects most people, there's still viable techniques for manipulating it (except for Flutter's CanvasKit which is an abomination more cursed than Flash), and honestly, we're still getting better at webdev, still learning, still emerging better libraries & best practices, & generally the urge to do better is here & slowly happening.
There's some really dark takes that we have to save the web from apps. That we should bring back Flash is one of the most unforutnate least justified most tragic hot takes I've heard though.
Your rant is focused so much on the actual implementation details of Flash that it misses the point that the abstract concept of a VM based application container/sandbox could have been a great thing. In fact, it was such a great idea that browser developers were forced into a pretty tough struggle to actually kill it in order to stay relevant themselves. Adobe's poor stewardship sealed the deal, not conceptual shortcomings.
Isn't that what we have? JavaScript is a VM-based sandbox. The difference is that JavaScript has more ready access to the DOM, but Flash was also able to do that, it just used JavaScript as a bridge.
The point is that you didn't need DOM. You had a canvas to draw things on and to handle clicks in. Now you need the DOM either way and it's cumbersome. It feels like trying to build a UI in a word processor. Text nodes are such a terrible idea...
Having a hypermedia standard is universes more interesting & powerful & enriching than what boils dowm to a way to generate gifs. Computers have dozens of ways to throw pixels at peoplecs faces and none of them are remarkable or particularly noteable.
Having a DOM, having structure, having a hypermedium is a source of immense potential & power. For both developer, but also, capitally & uniquely, for users too.
Your statement doesnt resemble any gui toolkits Im familiar with. Not Flutter, not Swift, not Gnome, nothing. The DOM closely resembles other ui construction systems & has similar ideas lile event handling.
And then the pretense that developers are the only thing that matter. The web is vastly better than apps because of the dom, because our systems are in a malleable hypermedia that ysers can modify eith userscripts, userstyles, extensions, eith whatever manner of accessible browser/user agent they please.
It's such sad thing to hear people advocating so strongly for the winnowing od possibility. Leaving all responsibility & all power with the app developer sounds perverse to me, sick, unworthy of being called a part of the internet. Not only does "just need something to draw on" not reflect the needs of developers, it represents an mortal threat to user agency.
The very big difference between the web and a proper GUI toolkit is that in GUI toolkits, inline elements aren't a thing, period. Text nodes also aren't a thing and don't mess up your layout when you least expect it (argh). You need to explicitly create a "text view" or label of some sort to display text. GUI toolkits also usually offer layout algorithms that make sense for GUIs. Oh and did I mention that they have sane defaults like not insisting on using the intrinsic sizes of things unless you explicitly tell them to?
Another property GUI toolkits have that the web lacks is that the GUI toolkit is usually made of the exact same kind of code you're writing your app in. There's a much tighter integration between the app and the toolkit. The app can extend it much more sensibly by, for example, implementing custom layout algorithms. With the web, there's this issue of the browser implementing all the layout and drawing and doing all the work and you can only provide input parameters to these hard-wired algorithms — you can't build your own.
Yes, I'm aware of those layout and paint worklets being worked on. Yes, they solve some of these problems and thankfully move the web platform closer to feature-completeness. It's still a mess though.
There's a lot here I think doesnt have much merit i fact, is bias & predisposition, a false belief that only simpler/dumber/less is permissable. I disagree & see no basis in fact, no evidence for any of these claims to importance & difference, but I also think nearly no one can claim authority, has any real idea. I dont believe this expansive platform is to the detriment, but Im also capable of allowing for differing views, wrong though I think they be. Neither side has much to say for itself. The first claim being that inline rendering capabilities are actively harmful, that the web's capability is a point for the opposing side starts me off with extreme doubt, but in spite of my extreme doubt it's in an unresolved state. We need more & wider possobilities to assess; I dont see that recognition that we need to know more to decide in the web-detractors allowed-fors.
Where I really want to pull the emergency break & call for reassesment is when I hear promotion of turning usercs experineces into mere pixel pushing videos. I still cant begin to express enough what a colossal & masive civilizational downgrade it would be to reduce the web to moving pcitures, animated pixels, which again seems like ongoing chorus of this post. Layout can preserve textual information, but the idea that we just need to let devs paint whatever and fuck hypermedia, fuck structured information, fuck text: it's ballistic out of this world demonic. Truly fallen a proposition. There's so many people eho recognize for example Flutter & it's infernal CanvasKit as the enemy, as a thing no one else can read or understand but which the app can unmediatedly foist upon us. Instead of a shared medium where both sides have respect & powers, there's this ongoing deeply authoriarian undercurrent ehich has infected the world, thay says only the app's concermd matter. That hypermediums are irrelevant- 0% of importance is information & shared mediums, 100% of importance is the top down imposed experience. Users get no say, browsers get no say. To me, to many, this is as dark & bleak & sad a world as could be imagined, forsaking every gain & advance at interconnecting the world for a ludicrously totalitarian view of what software is for.
You still have the canvas, and it's perfectly easy to draw on that and handle events in JavaScript. There are a number of applications that work that way.
That said I disagree with the idea that using the DOM is bad - I suspect it's cumbersome to you mainly because you're not used to it. The number one benefit of the DOM is that user-facing controls are largely consistent. If I want the user to type text into a text box, I can just use a browser-defined element, and the user will be able to interact with that exactly as they expect. I don't need to reimplement the whole text input and display process, because it already exists in the platform. The same goes for all sorts of controls and interactions, from zooming to select boxes.
Moreover, assuming this DOM is built up in a way where the semantics are embedded in the elements themselves, then it can also be used in different ways. One user might use their browser to render the DOM into something that can see on their screen, while another might use their browser to read the element contents aloud. One person might use their mouse to interact with the system while another might use their keyboard. Accessibility is built into every application built using the DOM - it may not be ideally presented in some situations, and it's still possible to get things wrong, but by default a blind user will at least have a chance of using the system. In contrast, a canvas-based application will need to reimplement accessibility from the ground up (usually in the form of a secondary hidden DOM tree).
Exactly. When I first did a web front end it felt exactly like customising MS Word with VBA. No matter what you put on top of it the roots poke their heads through and it feels like a mess.
Yes, yes. Flash (with AS3) was a first-class web application platform. There were buttons and views and "movie clips" and other stuff for you to place on a blank canvas, all very customizable. Then there was Flex, a full-fledged yet relatively lightweight application framework built on that foundation. You created your layouts with XML, with live preview. There were Android-like layout containers (emulating Android's LinearLayout with HTML+CSS is still not quite trivial in 2022 — the defaults on flexbox are bonkers) and there were ListView/(UI|NS)CollectionView-style lists with reusable cells, among other things. This was 15 years ago! I can't even begin to imagine how many workarounds one would need to implement a list with reusable cells with HTML+JS even if targeting only the latest Chrome and Firefox.
HTML is a document format at its heart and there's no getting around that, but <object> is/was a nice escape hatch.
>Isn't that what we have? JavaScript is a VM-based sandbox.
JS is unfit for the task. It is a dynamic scripting language introduced by Netscape for the only purpose of adding a bit of interactivity to web pages, not to create large apps.
.NET and Java are much better for the task. The VMs support better languages with better libraries and more sane ecosystems. And the performance would be much better than that of JS.
And is easier to write an application using Xamarin or MAUI then using React.
When you write Java or .NET apps you write to target a computer which is a much better model for the apps then Web.
With "app languages" you can write apps better, faster while having better performance and more capabilities than using dynamic scripting languages like Javascript, Lua or Python.
Operating systems and browsers are apps too. And we don't use Javascript to write them.
You can write anything in any Turing complete language. But you'll be a fool if you attempt it for anything but fun.
I think what your describing is mainly your preference - which isn't in itself a bad thing, the lack of real diversity in browser scripting is a problem that is slowly being solved as WASM becomes a more viable target.
That said, some of your statements seem to be simply false. Javascript engines are at this point about as heavily optimised as Java and .NET runtimes, and a quick scan through a few benchmark sights seems to indicate that, with a few exceptions, the two perform similarly well. Certainly, there is no guarantee that a naïve implementation in Java will necessarily be faster than a similar one in Javascript, in the way one night expect with e.g. C and Python.
Moreover, JavaScript is regularly used in all sorts of applications and systems - Gnome, for example, uses JavaScript for various plugins and utilities, an increasing number of applications are written using Electron or other webview-based technologies, even browsers use JavaScript for a significant number of controls (e.g. the devtools for most browsers are written in JavaScript). So clearly a lot of people see value in writing all sorts of applications in JavaScript.
The rest of your complaints seem to be largely your opinion - again, perfectly valid, but other people will have different opinions, and so the value proposition for JavaScript will be different for them. For example, for me, building something in React is a cinch, whereas Xamarin would take a lot more work. And the ecosystem of JavaScript may not be perfect, but it's very well oriented towards building front-end apps, something that isn't as true of Java.
JavaScript VMs are inherently hampered by language design choices in JS. The dynamic typing and prototype based objects limit JIT based optimization for the full JS massively. Java and .NET have fully static typing which allows their JITs to be completely certain when they are translating code. JS JITs constantly have to add overhead in the form of escape hatches to deoptimized code if e.g. expectations about variable types are being broken at runtime.
Yes. The standard itself (the swf file format, the AVM bytecode, etc) is actually open. To their credit, Adobe has all the relevant specs on their website.
None that I know of. Of course it would be nice to have an open-source editor as well, but an open-source player is much more important. You can get by with abandonware for the creation side of things, but you can't ask your site visitors to install abandonware that is known for an astonishing amount of scary vulnerabilities (if they use an OS that was supported in the first place).
> I miss Flash. I hope it makes a comeback eventually.
Flash was great for developers, but terrible for users. The only good user experience was "flash games/animations" and even then they weren't responsive and a little clunky.
The Flash I remember was bloated "Flash" websites that had No HTML, No url paths, No SEO metadata, Terrible for accessibility.... but it was easy to develop for I guess...
Why not just use Java and .NET? They have pretty capable VMs which support lots of languages: Java, Python, Clojure, C#, F#, Visual Basic, Python, C++ and others.
>Why does it have to be so siloed? What if I want documents with a slight bit of inactivity?
You aren't allowed to have that, because it's not profitable for the web developer crowd's bosses. So your "slight bit of interactivity" becomes "several megabytes of surveillance and advertising".
I think it's point 2. In the article, that it shouldn't be compatible, as you'll end up having to implement all of chrome again.
And the anecdote about adding the tracking code for one thing, but all the other market segmentation information getting turned on afterwards because it can.
But yeah, I do want comments on my blog posts, and hn linking to docs.
So are you saying you just want the web as it is? If not, what would you change? How would you prevent it from becoming what it is now?
I don't see why a document couldn't have a link to an application that opened next to it, so that you could view documentation and an application together. We should utilize the organizational ui paradigms built into our operating system, not use the system as a launcher for Chrome.
The effort is being done whether its all in one application or split into two.
It has to be siloed because if it isn't, you won't be able to find the document you want to read without running application code, as we see with the modern web. It's not a search issue, I find the documents I want to read just fine, it's just that they come with megabytes of executable code I don't want to run.
It would be nice if a client could only implement the rich stuff that it wants to, unfortunately, when the rich stuff is all different everywhere, it means only clients that support all of it get used, hence the current state of web browser development.
The changes we need are around people, improving liberal arts education; and ownership, having government run alternatives to most things like search, login, and payments
