Hacker News Reader

Comment by amitport | Hacker News Reader

Why is it scary?

It's the end of being able purchase any kind of perpetual license to your software. It'll all be on the web and it will be paid per month. When that meets a company with an aggressive sunset policy or if they have an outage it won't be a good time.

It probably requires updating user protection laws to deal with new business models and enforce interoperability.

We are still in the Wild West Phase of SAAS.

We already have a draft of them from timesharing days.

Seems unlikely. Even if that is a trend right now, if there is a need for other paradigms, then there will be people making and using them.

But with opensource software I can run it on any server I want (AWS, Azure, my own). I'm still in control.

I do this for all sorts of applications.

One could also see it as an option that makes contributing to open source so much easier for small edits. There are plenty of times when I am working that I would make a small change or refactoring to a project, but the idea of cloning, setting up an environment, figuring out how they run tests, etc. makes for too much of a barrier to entry.

If someone says "The trend towards smaller cars suggests trucks and SUVs will cease to exist.."

Not going to happen..

With a piece of software I physically own and that has an offline activation mode (tips hat to Jetbrains), I can be reasonably certain that I can keep using it for as long as I can maintain some kind of virtual machine for the host OS. I will not be affected in my usage of the software by any decision the software maker decides to do in the future - think UI overhauls, deprecation of features -, the balance of my bank account or the software maker goes bankrupt or bought out.

If I am skilled enough, I can mod the piece of software to do whatever I want (this especially applies to games), or can swap out pieces with other pieces (e.g. replace the built-in compiler of an IDE with a different one).

A pure SaaS environment? I'm completely at the mercy of the operator now. I am locked in into whatever decision the operator makes, I depend on them keeping their service available 24/7 (because when they go down, I can't work and make money), I depend on them not getting bought out by a competitor that then decides to close up shop (either to get rid of competition, acqui-hire or the specific SaaS service is unprofitable), I'll have to pay whatever price the operator wants (which is particularly insidious given the SV model of price dumping, monopoly formation and subsequent extortion), and in most if not all cases I have no way of modification (userstyles/userscripts just don't work in compiled JS/CSS apps any more without a lot of work). And to top it off, for many SaaS solutions I have to pay money to keep using it under a contract, which is an obligation on my future budget.

Ellen Ullman quotes Whitfield Diffie in her book Life in Code and I think he’s spot on:

> We were slaves to the mainframe! he said. Dumb terminals! That's all we had. We were powerless under the big machine's unyielding central control. Then we escaped to the personal computer, autonomous, powerful. Then networks. The PC was soon rendered to be nothing but a "thin client," just a browser with very little software residing on our personal machines, the code being on network servers, which are under the control of administrators. Now to the web, nothing but a thin, thin browser for us. All the intelligence out there, on the net, our machines having become dumb terminals again.

That doesn’t really explain why it is bad, it just asserts that “dumb terminals” are bad.

I just want to add that running in the browser does not mean running in the cloud or web. I actually once worked on enterprise software that used a browser as GUI. That's not at all bad. Of course there is always room for improvement.

By a reasonable guess your app was distributed as a binary that spun up a local web server and automatically pointed the user's browser to it. That's a perfectly fine approach for some use cases, but for many others, even the server binary isn't needed.

An extremely underappreciated approach for development and distribution is targeting the browser as a sandbox for fully local applications (embodied in static files—or better: as a single file). I see lots of people making apps and throwing them up on GitHub Pages, but rarely do the developers package them up into a form that you can download from the Releases tab from the associated repo and then double click to run. At best, they'll point at the repo with instructions in the README about running npm or yarn.

(Then again, if their build processes would also target the browser's JS engine and standard browser APIs instead of NodeJS and its proprietary ones, then the entire exercise of setting up an NPM-based development environment need not exist, either. Oddly enough, people who think of themselves as JS developers and spend their days writing web apps seem to either really dislike the thought of actually using the browser, or they're so afflicted with tunnel vision that they've missed the obviousness of using the browser runtime in this way.)

All your Data are belong to us?

Scary was probably not what I meant, more like paradigm shifting change into something unrecognizable from my experience.

Reply on news.ycombinator.com