The browser is indeed an application platform. Even HackerNews is an app, although it uses a minimum of browser functionality.

Maybe you don't want things like videochat or paint programs or music learning apps to run in a browser, but lots of people do.

Imagine if Firefox said "we're not going to let any web page access the camera"... their market share would probably drop in half overnight.

I wonder if and when the splitup will happen between the "text" web and "app" web.

I know you can disable Javascript, but this is still different.

I am have dreamed of a browser that lets me create desktop shortcuts to webapps and then pretend as if the webapp is its own fully independent application but all webapps would still run in the same browser instance.

Chrome lets you do exactly this: https://support.google.com/chrome_webstore/answer/3060053?hl...

I imagine other browsers probably do, too.

What would Hacker News be? How about email apps such as Gmail or Yahoo mail?

Both can be the text web.

I am fairly certain that I have posted to Hacker News with Lynx, which means that everything is handled server side.

About 20 years ago, I created a personal webmail client that was implemented entirely on the server side.

The distinction is important and while it would produce a very different web, but it does not mean a web of static content.

Well, I can certainly login, navigate to this comment, and then reply with Lynx.

It's not a great experience, mind, but it does work.

Upvoting and downvoting work too last time I checked.

The three categories I would make are: text, static forms, and SPAs

There are email clients.

>Do those clients work on my mac, my chromebook, my windows box, and my android phone?

Yes.

>Call me crazy, but I prefer web apps for that kind of stuff. I'm also glad I don't have to download an app to use Hacker News.

Web means HTTP, Email is POP3/SMTP/IMAP. Different protocol, different programs. That you can use a website to view and send emails is not the default case and is merely a interface to those protocols.

I understand how email works. "Default case" is a matter of interpretation. Most people today use web based email (at least on computers as opposed to mobile devices), and it is much easier for most people to set up and get working than using a native client. The vast majority never think about wire protocols. I have implemented both HTTP and SMTP in C etc back in the day, but that is not relevant here.

Regardless, I said my preference is to use web based email, that's all.

It's not about how people use it, the RFCs are clear on this.

What's "it"? "The relevant issue"?

Because the relevant issue is most certainly how people use it. People use web browsers to read their email. Why is what the RFCs say important to this?

Because the discussion above was about email. A browser is not a mail client (as in MUA). Unless a browser implements the RFCs regarding email, it's only a web browser.

>How about email apps such as Gmail or Yahoo mail?

So the answer is: It doesn't matter as those are not email apps. They are email frontends for a service that implements mail. If people think differently - it's their wording, but still a wrong one.

So you're just spinning on the definition of "email"? As opposed to recognizing that a particular activity people do (which I call "using email" but maybe you have a different word for), is very often done using a web browser.

Why you'd think debating the semantics of the word "email" is relevant to the discussion is beyond me. It makes me almost wonder if you are attempting to parody a certain type of pedantic technical person.

Words matter.

Average users won't do it.

Manual security = no security

It's kind of sad though because it's still 10X easier to build a browser app than a native app simply because of the wealth of highly-usable stuff written for JS.

Every time I have to build a GUI in Linux I just build a webapp that connects to a TCP backend on localhost because that way I can just build a beautiful UI in HTML/JS/CSS and I don't have to deal with the mess that is GTK, QT, TCL, TK, and all that crap.

Android programming is another can of worms and I'm frankly fed up with Gradle updates breaking my project every update and needing 79+ files, multiple cludgy steps for signing APKs, zipalign (wtf) and other crap just for a Hello World.

What would be nice to have is "installable" apps that use the webkit rendering engine but have full access to the system including directly opening TCP ports and direct access to /dev. These would have to be trusted apps obviously. Websites that load code without consent should be restricted, of course.

> Every time I have to build a GUI in Linux I just build a webapp that connects to a TCP backend on localhost because that way I can just build a beautiful UI in HTML/JS/CSS and I don't have to deal with the mess that is GTK, QT, TCL, TK, and all that crap.

I suspect this has more to do with the state of native Linux development tools versus Javascript dev tools then it has to do with the general case. Dev tools for Windows and iOS/ MacOs are fairly straight forward. Not sure about Android, since my burning hatred of Java has removed my desire to mess with that platform entirely. (I know Kotlin exists, still not interested)

Update: I'm basing my comment of what it's like based on the quoted comment, not making an assertion about how good/ bad it is.

> Dev tools for Windows and iOS/ MacOs are fairly straight forward.

Can't speak much for Windows, but the Apple dev story is pretty good. Platform SDKs are deep and capable, if sometimes not well documented, and there's a clear "right" way to do most things. One can build a "world class" app with nothing but Swift+UIKit and few or no third party libraries. SwiftUI is rapidly improving this too, bringing a fully native "modern" reactive approach that works across all Apple OSes.

Xcode can be a cantankerous beast at times but it's been getting a lot better in recent releases.

> Not sure about Android, since my burning hatred of Java has removed my desire to mess with that platform entirely. (I know Kotlin exists, still not interested)

It's slowly improving but still very much a mess. Jetpack Compose looks to be poising itself as the SwiftUI of Android and that will no doubt improve things, but I have doubts that Android development will ever be as nice as iOS development is.

> IntelliJ Idea is a fantastically better IDE than XCode from a functionality standpoint

This is not my experience, I've never quite cared for all the finicky setup needed to get things right, and it always feels a bit laggy. (Though IntelliJ is a world better than Eclipse).

It's definitely more laggy, but in terms of everything else, it's light years ahead of Xcode:

1) code navigation, editing, refactoring 2) integration with Git/GitHub, Issue Trackers, Cloud Providers 3) external build system support 4) multiplatform editing (java, js, typescript, kotlin, python, etc) 5) integration with testing, continuous integration, deployment 6) code analysis, finding problems 7) tons of special support for DSLs and third party frameworks

The only thing XCode is better at IMHO is UI building and OSX instrumentation. If you're writing tons of code that doesn't have a UI, especially for cloud backends, I don't think you'd use it.

Even simple things, like language injection, work wonders in the editor window. Having the IDE know how to syntax color, check, and code complete SQL, CSS, HTML, Regex, etc inside strings is a huge help.

I spend 15 years on emacs, and the last 15 on InteliJ, and having an editor that slices and dices code in a myriad a ways with easy to use automation, and actually indexes the code and builds a deeper understanding of the totality of your project is well worth it. I just wish it was less laggy in the UI.

If I was writing an iOS app, sure, I'd use XCode, but I can't envision being it general purpose for anything else, unlike the versatility of other competitors like VSCode.

> If I was writing an iOS app, sure, I'd use Xcode, but I can't envision being it general purpose for anything else, unlike the versatility of other competitors like VSCode.

I would never expect Xcode to be the best general purpose editor/ IDE. It's good for Swift/ iOS development which is what its build around. Personally, much of the time I'd rather have a performant editor than one that has a million bells and whistles.

> Dev tools for Windows and iOS/ MacOs are fairly straight forward

Are they? It's probably been a decade since I touched a native GUI (and I was without a mentor and working on already-old software) so I legitimately don't know. Using something like Visual Studio's form builder was fine enough, but it was not a very expressive toolset as I recall.

Web you can get started "instantly". Your browser covers most of the tooling you need and you can tweak any live site.

I don't like that that's how it is. From an abstract perspective I'd rather not be working on web because it seems like we're trying to make a better car by building a bicycle inside of it. But the low bar for entry is hard to beat.

> Web you can get started "instantly". Your browser covers most of the tooling you need and you can tweak any live site.

Obviously you can splat some HTML into a browser and get instant results, but once you start talking about apps with even moderate amounts of interaction, the simplicity of web apps falls away quickly. If you are talking about a sophisticated app, I don't think the complexity is any less when you are using javascript/ React versus Swift/ UIKit. The big win I've seen for javascript/ web apps is the fact that you are reasonably platform independent, obviously if you use Chrome and Chrome specific APIs, that falls away too.

I had to get back into C# a year or so ago to build a commercial internal production management application, WPF with XAML was exceptionally pleasant to work with and the final product just worked with few issues.

It felt weirdly like writing Vue-like code.

Microsoft nailed it imo, VS2017 and C# have come along way since I used to do .net 3.5 stuff.

I really liked C#, it’s http and a sync/await stuff was excellent.

Why not just use GTK or Qt?

GTK:

    import gi

    gi.require_version("Gtk", "3.0")
    from gi.repository import Gtk


    class MyWindow(Gtk.Window):
        def __init__(self):
            Gtk.Window.__init__(self, title="Hello World")

            self.button = Gtk.Button(label="Click Here")
            self.button.connect("clicked", self.on_button_clicked)
            self.add(self.button)

        def on_button_clicked(self, widget):
            print("Hello World")


    win = MyWindow()
    win.connect("destroy", Gtk.main_quit)
    win.show_all()
    Gtk.main()

HTML:

    <html><body>
      <button onclick="alert('Hello World')">Click Here</button>
    </body></html>

Now try implementing a swipe tab UI in GTK with animations and embedded video. In HTML you can probably import someone's awesome library .js file and be done with it in 5 minutes. Video is a snap. In GTK you have to deal with some idiotic factories, pipelines, sinks, faucets, and other god-knows-what abstractions. In HTML it's just <video>.

You could also use a glade file and only worry about functionality on the code itself. It's not too bad.