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.
@mathew couldn't have said it better myself. but i tried to say it.
@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.
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.
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.
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.
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. https://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.
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.
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?
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.
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.
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 @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.
> 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.
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.
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.
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!