3 ms·

> I struggle to imagine how it could realistically be not complex. Pretty easy, we should have had 2 standards, one being "Web for applications", built on a VM

• dvh 1y ago
  Nobody would be using webpages version and everybody would be using app version.
  • deleted 1y ago
    [deleted]
  • strogonoff 1y ago
    I would argue that a good layout engine for pages could see good use. See Gemini/Gopher—people like minimalism, but having to use a separate browser makes it probably too niche. Contrary to what was stated in the suggestion, it’s hardly a solved problem—improvements are being made at a steady pace (grids or { text-wrap: pretty } come to mind)—but it is interesting to imagine, especially if there were extra compelling reasons for engineers to restrict themselves to purer hypertext document API if possible (for example, it could be much more stable, while the app part could be unlocked to evolve more quickly but would be more demanding to developers keeping their webapps up-to-date; search engines could prioritize it; there could be hosting services specializing in it; and so on). One counter-argument is that you can’t neatly separate the two and engineers will definitely want to use both; one way around it I can see is if hypertext document functionality was possible to use from within the webapp somehow, but I haven’t given it that much thought obviously.
  • graemep 1y ago
    I would love to use the web pages version, both as a user and on websites.
  • ezst 1y ago
    I think it's a reasonable take after 15 years of seeing CSS/HTML/JS being abused for everything and more (when all you have is a hammer…), with the result being that many simple static pages are nowadays monstrous JS apps. My conviction is that, had those technologies stayed simple and focused on delivering the "Document" use-case, turning everything into an app would be a much bigger bridge to cross. That's essentially where the web was at before the HTML5 days: you could already go as fancy as you wanted, at the cost of pushing your users into a java/flash applet (and through longer loading times, high CPU/Memory requirements, …), and that clearly wasn't the norm.
• rizky05 1y ago
  [dead]
• davidmurdoch 1y ago
  You'd still have all the same backwards compatibility problems with the "Web for applications" stdlib and UI framework as we do now.
  • justinator 1y ago
    You just use the novel solution of downloading the whole thing as an applet.
• graemep 1y ago
  We had multiple implementations of Java, but if still failed for that reason. Even if the concerns had been completely addressed MS did not only want to stop Oracle taking control, it wanted to establish control itself. Was Java any worse from a security point of view than what we have now?
  • achierius 1y ago
    Yes, significantly. The JVM just flat out does not provide a sandbox. Remember the bad old days of clicking on a suspicious link and getting pwnd? That's what we'd have if it weren't for modern JavaScript engines
    • graemep 1y ago
      I thought the JVM had permissions restrictions in the days of Java applets?
      • ezst 1y ago
        I suppose it had, but as a large codebase written in a memory-unsafe language with unrestricted system access, in an era where browser plugins weren't sandboxed by design, it was a cat and mouse game.
• andoando 1y ago
  I struggle to see the reason why web pages and apps are even two different things. The browser is really just a cross-platform platform for building applications.
  • n4te 1y ago
    Yes, a terrible one. That's what the article is about.
    • andoando 1y ago
      What I mean is, I dont see why browsers even exist. There should be a singlular framework for creating desktop apps.
      • conartist6 1y ago
        There is. It's called a "browser"
      • n4te 1y ago
        Ah. One difference is a normal desktop can access a lot more or even all of your system. Otherwise cross platform UI toolkits exist: GTK, Qt, Swing, SWT, etc. They could be great but they aren't, not because it can't be done well just no one has managed to do it well. They could technically be sandboxed but they aren't, or not well. Java applets tried long ago and a lot of systems got owned. You'd never design from the start the bonkers HTML/CSS, box model, and other junk we are stuck with, but browsers have a number of good aspects that you'd probably end up with in a complete redesign. The problem is multifaceted. UI toolkits are very hard to do well (I have a lot of opinions on this, and my own crossplatform toolkit), even on a single platform. Just that alone is huge. There are basically no overall great UI toolkits, even if some have good parts. Even a theoretical great UI toolkit will have quite a task to achieve parity with what browser UIs can do. If we could get past that (spoiler: we can't, no way in hell) then we'd also have to be willing to ditch all the legacy browser stuff to switch billions of users and devices to something new AND we'd still have many other big problems to deal with: getting the committee/everyone to agree without ruining it, security, privacy, etc. We've accepted we can't really fix it, so the only thing we can do is keep extending it. That's how we got here.
• postalrat 1y ago
  And how about blind people, bots, accessibility in general? I don't remember java and flash handling different screen resolutions like desktop, tablets, and phones.
  • wpm 1y ago
    Yes, because the author of the comment didn’t explicitly carve out a moment to comment that Java/Flash were not great for accessibility, it must mean that in their hypothetical world where web applications that needed rich interaction and client side processing where based on Java/Flash type runtimes, it would have stayed shit for accessibility. I’m sure the person you were referring to doesn’t want to make the web shit for the blind. Calm down
    • postalrat 1y ago
      To them the web probably isn't much more than doomscrolling video content.