On web 'apps'

[moonbat]

I'm coming from a decidedly outdated perspective, yet one that Pale Moon still follows in spirit and substance - that a web browser is a remote document viewer and not a virtual machine for remote applications.
The nomenclature is off, for starters - a webpage is not an app. It requires the browser engine to be rendered at all before it can exchange any information with its server, and one can as well create a shortcut to it. If the argument is that it shouldn't be sharing data with the browser or that it's 'inconvenient' to launch the browser in order to load a desktop shortcut - what is the workflow these days that does not involve keeping the browser running (often with a few thousand tabs for some weird bookmark not using people)?
Mozilla recently revived the concept for Firefox - with that browser's containers feature, you can already create a separate container to isolate a given website. I saw andyprough's howto on converting Tutanota into a web app for Pale Moon - it again boils down to a separate profile launched with a shortcut.

I so wish for the timeline where Mozilla realized the goldmine that their application platform could be and promoted the hell out of it after hiring decent technical writers to fix up the documentation - we would have powerful internet enabled cross platform desktop programs today written with just a knowledge of Javascript and XML (XUL), and each application would be extensible with addons just as Firefox and Thunderbird originally were. Far better than forcing a webpage to run in an isolated browser wrapper and calling it an 'app'.

[Nuck-TH]

This can be summed as that Mozilla platform could be Electron done right. Alas, despite being visioners, they failed to properly document, make accessable(xulrunner and stuff) and promote it.
And so we have what we have.

[BenFenner]

we would have powerful internet enabled cross platform desktop programs today written with just a knowledge of Javascript and XML (XUL)

Gross.

[Moonchild]

Gross.

What's gross about it?
To me it feels like it would be the best of both worlds: easy to maintain and write desktop applications with a powerful web-capable engine under the hood to exchange data with servers (instead of tasking a browser to compile and run all that on-the-fly)

[moonbat]

This can be summed as that Mozilla platform could be Electron done right. Alas, despite being visioners, they failed to properly document, make accessable(xulrunner and stuff) and promote it.
And so we have what we have.

Documentation has always been their Achilles' heel. Even what little is left that RealityRipple kindly backed up is so moth eaten and was submitted by external volunteers. It's amazing that for all the money Mozilla made from Google search, they couldn't hire technical writers to design proper documentation and keep it up to date with platform changes (the last part is even more important; incomplete or obsolete documentation is worse than none at all). Microsoft long ago understood that attracting developers was what would keep users staying on Windows; their MSDN and Visual Studio were unparalleled and every other IDE we have now has mostly copied features from VS.

Gross.

There's a whole range of XUL based desktop software that was written in the 00s. Especially Songbird - a media library, and Instantbird - a classic multi protocol IM. Both of these supported extensions written for them the same way as Firefox. And they would follow the UI conventions on each platform - Windows, Mac and Linux. Why is that gross, that too compared to what we have today? Now that's gross.

easy to maintain and write desktop applications with a powerful web-capable engine under the hood to exchange data with servers (instead of tasking a browser to compile and run all that on-the-fly)

Not only that. For years we've been hearing that the supposed drawback of desktop applications vs web based ones was deploying new versions to end users. The update server mechanism takes care of even that - in a corporate scenario one can set up an intranet server to push updates to the app, and use the same extension mechanism of XUL to modify it with newer features and functionality as needed, and sign the extensions here for further security. If they were provided zipped instead of as installers, then there's no need for local admin rights to update them either.

Mozilla was sitting on a goldmine. They needed to stabilize the public APIs, make proper documentation and then could have collaborated with others like the Eclipse Foundation to make an official IDE plugin for Eclipse (there was a separate third party one for a short while). Pitch this at corporates, and offer technical support to create a revenue stream.

The best part is that Firefox and Thunderbird were already prime and mature examples of what could be created with the application platform. It would be an easier learning curve for existing web developers to learn XUL and start on desktop applications rather than depend on C++ for various different toolkits as is the case.

Instead we are stuck in the shittier timeline, where their idea of a 'desktop application' is to wrap a full Chrome instance around a webpage and call it a day

[Moonchild]

For years we've been hearing that the supposed drawback of desktop applications vs web based ones was deploying new versions to end users

This doesn't even make any sense as an argument. for a "web app" you're forcing everyone to re-download the program every single time it's used. How is that a useful deployment strategy...?

[moonbat]

This doesn't even make any sense as an argument. for a "web app" you're forcing everyone to re-download the program every single time it's used

Tell me about it. There were earlier attempts at distributing desktop apps over the web - I've worked on Java Web Start, for example. It involved clicking a link to a .jnlp file (which was an XML manifest), and then the locally installed Java runtime would download the app to its cache and install a desktop shortcut. The shortcut whenever clicked, would perform an update check before launching the (now locally installed) app. This had more permissions than Java applets that used to be embedded in web pages and could access the local filesystem.
For whatever claims of being insecure, this along with other clientside Java technology seems to have been abandoned altogether after Java 8.

I have always hated web applications even when they started 25 years ago - crude forms on a page with rudimentary javascript and no XMLHttpRequest so the entire page had to refresh for any data changes. A native desktop app just feels more solid to use.

[andyprough]

I saw andyprough's howto on converting Tutanota into a web app for Pale Moon - it again boils down to a separate profile launched with a shortcut.

I'm surprised it's not talked about here more often. It's nearly an ideal way to open up an online password manager, or a cloud storage interface, or webmail, or a favorite online music or podcasting service. I make them for some of my biblical research services - since they use webgl more intensively than other sites it's an ideal situation to have a dedicated Pale Moon profile with different settings in about:config. At that point you might as well just make it a menu entry in your start menu, with the name and icon of the online service.

[moonbat]

At that point you might as well just make it a menu entry in your start menu, with the name and icon of the online service.

Yes, true, if the site in question requires so many separate settings of its own, it may as well launch from its own profile. Then again there's also containers - the old Priv8 on CAA works well with Pale Moon.

[andyprough]

Yes, true, if the site in question requires so many separate settings of its own, it may as well launch from its own profile. Then again there's also containers - the old Priv8 on CAA works well with Pale Moon.

I use Priv8, but I don't think you can have separate about:config settings in different Priv8 containers can you? I think Priv8 is just for separate cookies, cache, history, etc.

[moonbat]

Yes, correct - its primary use case is for multiple accounts on the same service, or for using sites that try to track you across your surfing. Put Facebook in its own container and it can't access what you do outside of it. (The last bit can be anyway done better with an adblocker).

[suzyne]

This doesn't even make any sense as an argument. for a "web app" you're forcing everyone to re-download the program every single time it's used.

I am not convinced that is the typical behaviour? I am pretty sure that my browser is storing web apps for the next time they are opened, and a download is only forced when there is an update. That seems to be what's happening when an app page takes noticeably longer to open because of a presumed update, while most of the time it loads much faster.

[moonbat]

I am pretty sure that my browser is storing web apps for the next time

That's more likely to be local storage, so the app can save its data locally instead of being in the browser cache.

[suzyne]

That's more likely to be local storage, so the app can save its data locally instead of being in the browser cache.

So? I didn't mention the cache and I never specified where I thought the web app might be located, I just suggested that I would be surprised if Google Docs (or whatever it is) is getting freshly downloaded each time I use it.

[moonbat]

So? I didn't mention the cache and I never specified where I thought the web app might be located, I just suggested that I would be surprised if Google Docs (or whatever it is) is getting freshly downloaded each time I use it.

Then you will be surprised. Just tested it out in Floorp after enabling the web apps feature, installing Whatsapp as a web app and turning off the network - it just opens the site in a popup window without an addressbar or other browser features, and says it can't load the site in question despite having already loaded it once. It's not an app in the sense of a program installed on your system if it cannot even load its UI without a network connection. Just loading a webpage with extra steps.

[suzyne]

Then you will be surprised.

Choosing the Whatsapp site is a curious web page to choose to see if web apps get freshly loaded each time you visit and open the web app.

Isn't https://web.whatsapp.com/ a web page that requires communication with your phone, and cannot work without a phone on the same Wi-Fi? Doesn't it specifically require a network connection so it can connect with your phone?

So, sorry, I am not surprised yet because I doubt that a site that simply won't work at all without an Android or iOS app running on my phone, is a good example of a typical web app. Like, for example, Google Docs.

[moonbat]

I am not surprised yet because I doubt that a site that simply won't work at all without an Android or iOS app running on my phone, is a good example of a typical web app. Like, for example, Google Docs.

I don't get this - what does the phone app have to do with it?

[Moonchild]

Might get hung up on the fact you need a phone and the app to have an account. But that has nothing at all to do with the "web app" (i.e. what runs in your browser) being what it is.

[suzyne]

I don't get this - what does the phone app have to do with it?

I am not a Whatsapp user, but I thought its web page was only a link to the app running on your phone, and not an actual independent app that runs fully in the browser.

Wasn't that the case before? And if is was, from what you say, I gather that it's no longer the case? And everything I said is nonsense!

[suzyne]

Wasn't that the case before?

Okay, so at least I know I didn't make that up, but my understanding is certainly out-of-date!