| ▲ | spacebanana7 4 days ago |
| I wonder how different things would be today if the web browser was originally designed for applications rather than documents. |
|
| ▲ | cbhl 4 days ago | parent | next [-] |
| There _was_ an outlet for this during the era of Windows hegemony: the object and embed tags. You had your choice of ActiveX, Java, or Shockwave/Flash in the 90s to write applications that you could then embed in the web browser. We stopped using these for a variety of reasons: they were difficult to make secure or cross-platform, GMail made building apps in JavaScript fashionable, and the iPhone (which explicitly would not support ActiveX/Java/Flash). |
|
| ▲ | brookst 4 days ago | parent | prev | next [-] |
| That’s what Flash was, and it was terrible. I think some things work better when they’ve evolved from simplicity to complexity, and application hosts seem to be one of them. |
| |
| ▲ | pjmlp 4 days ago | parent | next [-] | | Apparently not, given that it is exactly what WebAssembly folks are after, unfortunely with much worse tooling than Flash Studio had at our disposal. | |
| ▲ | ezst 4 days ago | parent | prev | next [-] | | Flash was terrible for producing documents, I suppose, but for highly interactive things, nothing matches it, even today (we are getting close in terms of what the web is capable of, performances are getting good, but the tooling and implementation effort/complexity is ridiculous in comparison). I don't think it's so much a question complexity than a question of using the "right tool for the job". Web technologies were never designed for that, never engineered to be extensible. Web apps is a hack, it's terrible, and that's all because of politics. | | |
| ▲ | ndriscoll 4 days ago | parent [-] | | Web technologies were designed to be extensible, for documents. e.g. HTML has had a built in templating engine and support for websites defining their own custom tags for 25 years. | | |
| ▲ | ezst 4 days ago | parent [-] | | Absolutely, the context there was "extended from simple Document/Markup jobs and into rich applications toolkits". |
|
| |
| ▲ | owebmaster 3 days ago | parent | prev [-] | | Flash was amazing and we lost a good amount of fun online when Apple killed it | | |
| ▲ | brookst 3 days ago | parent [-] | | The PRD for Flash was amazing, the implementation was pure crap. It had more bugs than functioning code, and more security issues than APIs. |
|
|
|
| ▲ | M95D 4 days ago | parent | prev | next [-] |
| Would you please stop trying to execute code on my computer just to show me a document? |
|
| ▲ | quotemstr 4 days ago | parent | prev | next [-] |
| We had a web for applications. It was called telnet. AOL, Prodigy, and others all had actually-pretty-sophisticated remote application deployment systems with vector graphics and fancy input processing. In the early days of the web, it was also common to write line-of-business apps using tools like Visual Basic, Hypercard, and even Excel (some things never change). The web won over all of them because, as history tells us, there are fitness advantages (e.g. platform agnosticism, easy introspection, and gradual enrichment) to evolving application capabilities into a widget toolkit that you just don't get if you try to make the optimal widget toolkit up front. If Tim Berners-Lee had made the web for apps and not documents, history would have been no different. Somebody besides Tim would have made a remote document system and we'd all be using that instead of something called the web. |
|
| ▲ | marcosdumay 4 days ago | parent | prev | next [-] |
| I'm really not sure. People tend to follow that comment with a list of requests for stuff that CSS does, exactly on the way that CSS does. Like separating the text and widgets rendering engines, and placement engines with "stick" orientations. |
|
| ▲ | vehemenz 4 days ago | parent | prev | next [-] |
| Or, imagine if they just froze the CSS spec at some point and allowed tools and methodologies to catch up. |
|
| ▲ | gjsman-1000 4 days ago | parent | prev [-] |
| One day, someone just needs to build an accessibility system for WASM; and maybe (additionally) an overlay system telling the browser that pixels X1, Y1 to X2, Y2 are selectable text. The moment we do that; we can theoretically implement any GUI framework we like, rendering to a <canvas> tag, without the current (serious) downsides. I’m looking forward towards more exploration of that direction. Then, we can mostly be free of HTML, CSS, and JavaScript defining how apps can be built. Those three tools that have long outlived their original intentions and have gone into complete duct-tape territory. AI however, might actually solve this sooner than we realize. Apple already uses AI to copy-paste text from images. I’m sure there’s plenty of R&D going on right now on using AI to describe what is on screen. In theory, maybe we can legitimately AI our way out of needing accessibility concessions, and off we go. Build your website in Flutter; or in MAUI; or in some DIY port of SwiftUI; whatever you want. |
| |
| ▲ | Quarrel 4 days ago | parent | next [-] | | While I am somewhat entranced by the ideal, presumably the realities of SEO and how most of the web is funded would put a stop to it? This is somewhat like the leap Figma has made. They were able to build their own walled-garden, offer value in it, and not have to worry about SEO. Most of the web is not in that position. I'd imagine we'd be better off with more such fragmentation, though? The internet was built to allow fragmentation, of protocols, of tech, of connections. It is just that, of course, most sites must flow to where the easy $ are. Let's just hope that enough good sites can escape the pull of easy $. | | |
| ▲ | gjsman-1000 4 days ago | parent [-] | | I think the short answer, is SEO is dying rapidly in the age of AI search engines. Search traffic is anecdotally being severely damaged when everyone can just get an AI answer; ad revenue is down especially after the pandemic; SEO spam is increasing from AI-generated websites. We might reach the point of saying, screw it, it hardly matters anymore. The web has been conquered by LOB apps, Paywalls, and Walled Gardens; and there’s no real way to fix that, but there is a way to fix the tech we are using. If anything, if we fully embrace “web as app engine,” we can fix some of these issues ahead of time. Maybe we have a standard entry point for crawlers (or users) requesting the raw text of a document. It’s better than being stuck in this awful in-between which we are right now. |
| |
| ▲ | kevingadd 4 days ago | parent | prev | next [-] | | Can't you already do this by creating a tree of invisible DOM elements with the right ARIA attributes? | |
| ▲ | tgv 4 days ago | parent | prev [-] | | And then we'll return to Java Beans and ugly, inflexible text layout, isn't it? | | |
| ▲ | pjmlp 4 days ago | parent | next [-] | | We already back there, apparently many haven't yet noticed that all those systems have been ported into WebAssembly, the main issue is that tooling experience is yet to follow along. Silverlight, Applets, Flash, all have WebAssembly runtimes now. | |
| ▲ | gjsman-1000 4 days ago | parent | prev [-] | | We’re already getting there. At one point we’re just ripping off the bandage. On the upside, most people don’t build their own frameworks. Implement it right in Flutter, MAUI, etc. in such a scenario, and almost nobody will be harmed. Also, for anyone who just says this is Java and Flash all over again - we’ve had plenty of technologies come full circle. WASM might be the one that gets us to full “web as app engine.” It already basically is, just badly. |
|
|