Follow

Sure, it sucks that the web was turned into a horrendous bloated platform for applications — but when you consider that the alternative we almost ended up with was everyone being forced to use Windows, it's not so bad.

· · Web · 2 · 4 · 9

@mathew really taking this thread miles. happy & a bit sad for myself too.

@mathew My understanding of the complaints I've seen raised so far isn't rooted in the hatred for an applications delivery platform. I think, on the whole, they're accepted as useful.

The pushback (at least amongst my peers) seems to be centered almost entirely around the extremely poor fit the current set of technologies seems to be for delivering that platform. And, with that in mind, I find myself sympathetic: HTML should stick with delivering documents. It's what it is good at.

Technologies such as WebAssembly offers some promise to finally provide a proper applications delivery platform. Unfortunately, nobody seems to be adopting it, at least not for that purpose.

@vertigo @mathew i'd love to have some follow up with some descriptions of this poor fit.

these days, it feels like most desktop apps use the same set of technologies. seemingly because they are easy to use, fit well in many circumstances, have great developer experience & support, active communities, wide library support, world class accessibility tooling, and, well, html works pretty damned well, in spite of the terrible terrible css crimes we keep committing against it.

i honestly can't remember most of the critiques. generally i feel like most are emotive, gesticulating, but not really identifying specific wrongs. i'm open, i'd love to really hear some good elaborations to chew on. but little so far has stuck.

@jauntywunderkind420 @mathew

these days, it feels like most desktop apps use the same set of technologies.

That's because they literally do. Vis. a vis. literally anything built upon Electron.

html works pretty damned well

HTML works. Just not "damned well."

Electron apps consume hundreds of megabytes to gigabytes, offering no better practical usability advantage than an app written in C and consuming a tiny fraction of the resources doing it.

i honestly can't remember most of the critiques.

Most of the critiques I've heard center around the above: absurd levels of resource consumption.

I've heard others complain about security models as well, but I am not versed in that domain, so I won't comment on those. I'll let others more knowledgeable about that follow up if they please.

Still others have complained also about applications not feeling native. However, for me, as long as I have the ability to cut and paste and drag-n-drop across applications, I'm OK.

@vertigo a specific grumble but here i go: too many people complaining about electron spend their next/near-by breaths complaining that the web is trying to do too much, has too many apis, shouldn't be a platform.

gee wouldn't it be great if you didn't need an entirely different set of statically linked libraries to run your app+browser? what if you could re-use the virtual machine (browser) that all your other (web)apps are running? that'd have way less overhead. alas they are often just poorly coded too, way too big.

so, net, alas apps keep writing themselves in electron because the web is almost close enough to compete on it's own, but is missing just a couple capabilities. less avoidable is that the web also won't let them do nearly as much spying as a native app will let them do.

@vertigo i keep thinking someone needs to lead the way & build an app that is a small localhost-only server that opens a web page. rather than smoosh a web-browser and a server-side engine together as electron does, provide some basically invisible native services to the client on localhost only. not to everyones taste but i'd love it so so much more than electron. i have no love for native apps.

@jauntywunderkind420

i keep thinking someone needs to lead the way & build an app that is a small localhost-only server that opens a web page. rather than smoosh a web-browser and a server-side engine together as electron does,

Maybe I'm misunderstanding, but it sounds like you're literally describing a web-browser and server-side engine, exactly as Electron does.

What am I missing?

@vertigo the app wouldn't bundle a browser. you'd launch it, it'd start the webserver, then call xdg-open (or your local non-portable prorietary equivalent) to open the user's preferred browser to it's address.
linux.die.net/man/1/xdg-open

there actually is some precedent here, now that i think about it. not sure why i haven't thought of this before, but this is how sabnzbd newsgroup downloader works: there's a small daemon, and almost all the interface is a webserver it hosts. there's a status bar icon you can hit... which opens your preferred web browser to it's local webserver. exactly as i described. github.com/sabnzbd/sabnzbd

the advantage is that you get whatever browser you prefer, with whatever extensions, and it probably uses gobs less memory since it's just another tab, not an entire browser stack & all dependencies just for the app.

@jauntywunderkind420 @vertigo also better security as electron apps allow direct local fileystem access

@dch @vertigo except you've started some random service / headless-app that is running with whatever privileges you've given it (usually your user privileges).

as per the sabnzbd example, you walk through the web app configuring the service, telling it where you want to download your newsgroup stuff to, & optionally setting up directories it will watch for download-lists to try to go get. you can use the webapp to upload download-lists too, but i believe the only way to actually get stuff out of sabnzbd is to go look on the filesystem where you in the web-browser told sabnzbd the daemon-cum-localhost-http-service to download to.

it's nice that there's at least some security condom, that you have some set of expectations you can apply to what you do from inside the web browser, but there is a local daemon free to run rampant, just like with electron.

@jauntywunderkind420 OK, I see; I missed the part where the browser wasn't included. My bad.

That's certainly a vast improvement, I'll admit.

@jauntywunderkind420

Based on what you've written, I think we want a common outcome. We just want to go about it in different ways.

When you write,

what if you could re-use the virtual machine (browser) that all your other (web)apps are running?

you pretty much made my point for me. This is why I am quite interested in WebAssembly, and would like to see it replace wholesale the browser/Javascript/DOM/etc. technology stack. It is an OS agnostic, good performing platform that has already proven itself useful for these kinds of applications. Why aren't we pushing it harder and developing it faster? It makes no sense to me.

less avoidable is that the web also won't let them do nearly as much spying as a native app will let them do.

I think there's ample evidence of webapps that do everything from keylogging to (more popularly) all manner of user tracking. Native apps are typically those which are significantly more secure in this area, because there are fewer nooks and crannies to hide malicious code in. The great beauty of server-side webapps is, bluntly, that their user tracking generally cannot be audited.

@vertigo @mathew That line of thought made me curious: SVG seems to be a better fit to build UIs with than HTML, but I couldn't find any project dping that. Back in the day IE was the problem but today: what's the catch?

@patrick @vertigo The catch is that a lot of developers aren't used to SVGs yet, and quite a few tools (including "frameworks" and "platforms") don't support using them everywhere.

Whereas for my own web site, the only bitmaps are the favicons (which still have to be bitmaps for some common browsers).

@vertigo The hard part of cross-platform application delivery is creating the GUI, and web technologies are easier and cheaper for that than basically anything else, at the cost of not providing a native UI experience. I'm not aware of WASM doing anything to improve that, but I haven't looked into it much.

@mathew

I'm not aware of WASM doing anything to improve that, but I haven't looked into it much

Exactly why I am upset about the situation.

@mathew @vertigo Yeah, my understanding is that the choosing a language to build a new platform on would be the easy part. There's lots to choose from!

There's APIs that need adesigning...

@alcinnz @vertigo
Right, it's easy to deliver native code cross platform nowadays, using (at least) Go, Rust and Zig and possibly other options like Kotlin. Putting a cross-platform native GUI on any of those is painful in the extreme.

@mathew @alcinnz @vertigo One of my big gripes is that all this web stuff is happening *at the expense of* comprehensive cross platform GUI libraries. We still have Qt, but C++ sucks. The biggest Rust GUI libraries have around 100 contributors. That's a small fraction of the labor that goes into Qt.

@mathew @vertigo

> web technologies are easier and cheaper for that than basically anything else

Web technologies are terrible at this, compared to libraries like Tk (which already had great cross-platform support and compatibility with a large number of scripting & compiled languages by the time web applications began to be used).

Like, I know this is Dave Winer's claim, but it doesn't stand up to any kind of evidence & we should stop blindly repeating it.

@enkiv2 @vertigo
Native look and feel didn't arrive until Tcl/Tk 8, by which time the web was already big and it was competing with Java.

(Also, it's interpreted, and nobody sane wants a stringly-typed language with incomplete Unicode support.)

@mathew @enkiv2 I think he's asking to look at the principle of the matter. Every problem you raise with Tk could have been addressed with enough interest in the development community.

@vertigo @enkiv2
Sure, but Java and the web had more commercial push behind them.

@mathew @vertigo

Not in, like, 1994. Tk had better cross-platform and unicode support than webtech up until development on it was essentially stopped (in the early naughts, because of... sun).

It has been easier to create a good-looking and performant cross-platform GUI app in TK than with webtech or java for the entire period that java has existed, and for the first 20 years it was easier to do internationalization in TK too.

@enkiv2 @mathew @vertigo Another example cross-platform UI library: WxWidgets. That one could be used in your choice of language, including (more recently?) JavaScript.

@alcinnz @enkiv2 @mathew To be fair, I've never had much in the way of good luck with wx.

Building anything beyond a very basic form has been something of an impossibility for me. (Actually, a lot like HTML-based UIs.)

@alcinnz @enkiv2 @mathew @vertigo Honestly, I would love to see xorg:// become a standard web address prefix. It's exactly what uou all are asking for
@alcinnz @enkiv2 @mathew @vertigo Also see LibUI, which uses native controls on Linux, Windows, and macOS.

@Seirdy @enkiv2 @alcinnz @vertigo @mathew one thing that the web has achieved is that I don't care so much about native looking UI any longer - as long as there is some consistency and good UX.

@jens @Seirdy @enkiv2 @vertigo @mathew Personally, I still prefer the native elementary UX...

But that's not *only* because I like the visual design, and I accept the argument it's not worth persuing in cross-platform apps.

Btw I'm using Olifont to toot this!

@mathew @vertigo

Let's say it's... any time from 1992 to 2007.

Tk doesn't give you native-styled widgets. But DHTML doesn't give you... widgets. (Java+SWING can give you native-styled widgets, on some platforms, but only if you check the platform and select the style from the set of styles yourself.)

And then, shortly after, Tk gets native-styled widgets in mainline, & DHTML still doesn't have widgets.

To this day, DHTML doesn't have widgets. You import somebody's hack to simulate them.

@mathew @enkiv2 @vertigo the interpreted argument is somewhat weak in my opinion. Look at all the Python software people are writing. Python is slower by orders of magnitude than any other language out there.

Tcl may actually be slower than Python, and that is an accomplishment in itself, but other languages had great Tk integration as well back then.

As for the the string typing, that's probably the biggest problem, but surely it would have had good Unicode support by now if it had remained popular. I'm reading some discussions on the topic and it seems obvious that they need a rethink of how the language itself worked. This isn't unheard of however. Remember that Python had to break compatibility with version 3 and one of the stated reasons was to improve string handling.

Sign in to participate in the conversation
Mastodon

Server run by the main developers of the project 🐘 It is not focused on any particular niche interest - everyone is welcome as long as you follow our code of conduct!