3 ms·

Hi Liam, What about dynamic websites? For example, a platform-independent chat app. Javascript has a place, although that place would be better filled by anoth

Hi Liam, What about dynamic websites? For example, a platform-independent chat app. Javascript has a place, although that place would be better filled by another language. PHP... yes, PHP can be completely replaced by other server side frameworks.

lproven 2y ago
> What about dynamic websites? An exact example of the kind of thing I'd like to get rid of. The UK PC vendor Elonex had the first ever webmail system I saw, called HTMail. It was impressive but it was a private in-house tool to give remote workers email access without needing their own machine with an email client. Wrong sales model. It the was followed by the indie HoTMaiL, based on NetBSD servers I think, which had the right model: a free public standalone service, paid for with ads. Of course MS bought it and ruined it. Webmail doesn't need Javascript and worked with pre-JS browsers and servers. > For example, a platform-independent chat app. Good. Let's eliminate them, too. They are bloated slow things that allow companies to hijack their own commercial clients' data. Stick to standard protocols, extend them if necessary -- XMPP 2, Matrix, whatever -- and document and publish the protocols. Make it possible for 3rd party client apps to connect. Pidgin was great and it takes about 1% of the RAM of a bare handful of these crappy Electron efforts like Slack. What you are citing as reasons to keep it are the reasons I want to see it dead.
- coolcoder613 2y ago
  These things don't have to be bloated. For example, I wrote a web chat once, called minchat (minimal chat) [0]. The frontend is written in plain HTML, CSS and JS, totalling ~5kb. The backend is written in Rust. There is room for programs that do not need to be installed. Examples are Flash, Java applets, and Javascript. Personally, I think some sort of UI thing based on WASM might be the way to go, but that's just my opinion. Can you think of any other way to run programs from the internet without installing them? Yes, SSH, telnet, remote access, remote X11, but with all of them, the programs are running on a different computer, whereas with web apps, they're running on your own computer, without costing them money, other than hosting costs. I never thought I'd be speaking for web apps, but I guess I'm not, not really. What I'm saying, is there is a niche, and that is currently filled by web apps. [0] https://github.com/coolcoder613eb/minchat https://github.com/coolcoder613eb/minchat
  - lproven 2y ago
    > some sort of UI thing based on WASM might be the way to go Oh dear hypothetical deity, please no! I can best respond by copying my own response from another place: Do you know Greenspun’s tenth rule? https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule It was about Lisp, so it’s an ancient thing now, but it still has truth. As far as the Unix/Linux/xBSD world goes, it can be generalised like this: Level 1: Any sufficiently complicated [container or VM management system] contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of Plan 9. Level 2: Any sufficiently complicated [bytecode VM or runtime environment] contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of Inferno. Wasm to me still smells very much like a second-hand, poorly-conceived, half-assed version of Dis. > There is room for programs that do not need to be installed. Sure there is room. But is this a desirable thing? Is it worth the price in inefficiency and insecurity? If it is, and I am not 100% convinced of that, then design it right into the OS from the outset. Any effort to bolt it on later will be fatally flawed.

lproven 2y ago

> What about dynamic websites? An exact example of the kind of thing I'd like to get rid of. The UK PC vendor Elonex had the first ever webmail system I saw, called HTMail. It was impressive but it was a private in-house tool to give remote workers email access without needing their own machine with an email client. Wrong sales model. It the was followed by the indie HoTMaiL, based on NetBSD servers I think, which had the right model: a free public standalone service, paid for with ads. Of course MS bought it and ruined it. Webmail doesn't need Javascript and worked with pre-JS browsers and servers. > For example, a platform-independent chat app. Good. Let's eliminate them, too. They are bloated slow things that allow companies to hijack their own commercial clients' data. Stick to standard protocols, extend them if necessary -- XMPP 2, Matrix, whatever -- and document and publish the protocols. Make it possible for 3rd party client apps to connect. Pidgin was great and it takes about 1% of the RAM of a bare handful of these crappy Electron efforts like Slack. What you are citing as reasons to keep it are the reasons I want to see it dead.

coolcoder613 2y ago
These things don't have to be bloated. For example, I wrote a web chat once, called minchat (minimal chat) [0]. The frontend is written in plain HTML, CSS and JS, totalling ~5kb. The backend is written in Rust. There is room for programs that do not need to be installed. Examples are Flash, Java applets, and Javascript. Personally, I think some sort of UI thing based on WASM might be the way to go, but that's just my opinion. Can you think of any other way to run programs from the internet without installing them? Yes, SSH, telnet, remote access, remote X11, but with all of them, the programs are running on a different computer, whereas with web apps, they're running on your own computer, without costing them money, other than hosting costs. I never thought I'd be speaking for web apps, but I guess I'm not, not really. What I'm saying, is there is a niche, and that is currently filled by web apps. [0] https://github.com/coolcoder613eb/minchat https://github.com/coolcoder613eb/minchat
- lproven 2y ago
  > some sort of UI thing based on WASM might be the way to go Oh dear hypothetical deity, please no! I can best respond by copying my own response from another place: Do you know Greenspun’s tenth rule? https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule It was about Lisp, so it’s an ancient thing now, but it still has truth. As far as the Unix/Linux/xBSD world goes, it can be generalised like this: Level 1: Any sufficiently complicated [container or VM management system] contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of Plan 9. Level 2: Any sufficiently complicated [bytecode VM or runtime environment] contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of Inferno. Wasm to me still smells very much like a second-hand, poorly-conceived, half-assed version of Dis. > There is room for programs that do not need to be installed. Sure there is room. But is this a desirable thing? Is it worth the price in inefficiency and insecurity? If it is, and I am not 100% convinced of that, then design it right into the OS from the outset. Any effort to bolt it on later will be fatally flawed.