Live data from Hacker News

It’s time to kill the web app

blog.plan99.net

361–370 of 717 posts

Re: It’s time to kill the web app

#361
It is a triumph of programming ingenuity that programmers have been able to accomplish almost anything via a "web browser".

Anyone can argue the benefits. If if there were few benefits the novelty alone might be enough.

But does anyone ever consider the costs?

The analysis I have in mind is: costs versus benefits of using a web browser to do x, where x is anything and everything, no matter how important.

The "costs" are not costs to the programmer to implement but costs to users, e.g., risk of having their personal data stolen.

To give an example, weigh the benefit to Equifax customers in having their data accessible through a web browser versus the cost of having their data exfiltrated without their consent.

Or, weigh the "cost" of having to dial a toll-free number to order a credit report and not have one's data stolen online versus the "benefit" of being able to order a credit report with a web browser and having that data stolen online.

Websites can be used to effectively disseminate public information, with relatively little security risk. For example, djb's tcpserver and httpd to serve static web pages. In continuous use since the 1990's, these have never had any security issues to my knowledge. IMO, this level of software is qualitatively different than software which is released with security flaws, which may or may not be later fixed (sometimes decades later).

IMO, using the web to distribute public information is a benefit that outweighs the costs. I am not worried about static websites, assuming the right software choices are made.

The blog post acknowledges this: "The web has issues as a way of distributing documents too, but not severe enough to worry about."

If Equifax had a static page served by djb's httpd showing number to call to order a credit report, I would be far more impressed than if they were running a "web app" to take orders online that connected to some backend database of user data. Because for that specific use case, a very limited use of the web is the smart thing to do.

I would like to see more people opining that, for "serious uses" i.e., where the risks to the user are potentially serious, the web has limited utility.

The current thinking seems to be that the web has unlimited utility. For everything. We all know that with enough effort the "web browser" can be used to accomplish almost anything.

I remember an RFC many years ago from Marshall Rose that said something like "the web is the new waist". I also remember in the early 1990's, people were afraid to send credit card information via web forms.

"Unlimited utility". Today, many young people, including many programmers, see no difference between internet and web. They are synonymous.

"Unlimited utility". Maybe utility should be weighed against costs such as security risks.

IMO, the web has limited utility.

Would you sacrafice a little convenience, e.g. option to order a credit report online, if it meant your data was not part of the data stolen from Equifax? I would.

Re: It’s time to kill the web app

#362

People used to do that, in 90s CGI scripts were usually written in C, or even assembly. And let me tell you since I'm old enough to remember it: no, it wasn't a great experience at all. It was actually quite horrible for web developers from the today's perspective. Development was slow and painful and hard to debug as hell. Also, it wasn't secure at all, hacker usenet groups were all about stack overflows back in tho…

And can anyone still read all that Perl? I used to speak Perl but I know I'd be far better able to understand some C I'd written 20 years ago than any of the Perl I did back then.

Re: It’s time to kill the web app

#363
post #240

Earlier quoted context omitted.

Gridbox and Flexbox largely make layouts sane again.

This to both. However, the problem with the web is there are old implementations that must be maintained in browsers for backwards compatibility. The issue with this is that it increases the barrier to entry for web development because it's much harder for a new person to even know what options to gravitate to. Of course, there are books and guides to help people, but how would someone figure out which guides are wor…

The old implementations are going away a lot faster than any greenfield environment can totally replace the browser.

Re: It’s time to kill the web app

#365

How about using an app:// protocol for compiled apps with security in mind, meaning sandboxed and no filesystem access? Http is for hyper TEXT, not hyper BYTES. Wasm is a great opportunity to reinvent web apps. Please don't fuck it up.

how many things have been described so far as "sandboxed no file system access" yet the sandbox is breached?

Re: It’s time to kill the web app

#366
post #257
post #233

Earlier quoted context omitted.

I used vb6 20 years ago and have recently (quite unfortunately) had to learn html/js/css basics. The web is hot garbage for displaying form data compared to microsoft tools circa 1996.

The web isn't the place to look for good tooling. Properiatery low-code tools built over the web are a better starting point.

I prefer no-code to low-code solutions.

Good lord I hate this buzzword bingo. How the hell are proprietary low-code tools better? In what world is that a sane response?

Re: It’s time to kill the web app

#367
post #64

>In part 2 I’ll propose a new app platform that is buildable by a small group in a reasonable amount of time, and which (IMHO) should be much better than what we have today... Next time: how we can do that. i look forward to that article. This one, on the other hand, seems a little pointless. Does the web have problems? yes, absolutely. But I have a hard time believing the best way to solve them it to tear down every…

I agree. People seem to think that there was a time when the internet was better than it is today. Well, I've been 'online' since before the web was world wide. Frankly, it was never good. In fact, it is better now than it has ever been. It's just people choose to use the worst parts of it. I've seen the various tech that was supposed to rebuild and revolutionize the web. It's just created more kludge. It's just lips…

Kudos for "lipstick on a pig". My thinking entirely. I don't really understand how the web got so broken. But you're right it's not going to be torn down any time soon, any more than the human eye will unevolve to fix the blind spot. Like biology, the web will evolve with kludge upon kludge, as long as it kinda works.

I think the best hope is for some language/platform that abstracts the whole thing away safely and lets you pretend it's not there. (And yes, I'm sure there are hundreds of these already. We just need to all agree on one!)

Re: It’s time to kill the web app

#368

Earlier quoted context omitted.

No kidding. I'm at the point of almost exclusively developing webapps. Universal, instant, and powerful. It's the perfect platform.

It's really not. HTML and CSS are far from ideal for making applications. JS has gotten better, but it still lacking in some ways. And there is no IDE for the web, whereas Smalltalk had one in the 70s, and numerous ones have existed for other platforms since then.

IntelliJ has multiple IDEs for web development, or programming text editors like VS Code and Sublime.

Even Chrome allows for a very fluid editing and debugging experience. Half the time I write my code directly in the browser.

Re: It’s time to kill the web app

#369
Nothing you’ve wrote here is surprising to me. I’ve never found the web app drumbeat to be compelling. The insistence that it’s the be all end all is myopic and usually the domain of those who are trying to protect turf rather than create great experiences that are secure, powerful, pleasing and fantastically useful.

Thank you for stepping up as a full stack developer and presenting a case without obvious bias in favor of the one web to rule them all. I appreciate it.

John-Michael Scott - a guy who’s been around a long time and watch this app evolve...

Re: It’s time to kill the web app

#370

Earlier quoted context omitted.

I'm having a hard time seeing how having separate control and data streams would have an effect here. Using FTP to retrieve a document isn't more secure than HTTP... the problem is in how the document itself is parsed. If you added a separate side channel for requesting data (a la FTP), you'd still have the issue of parsing the HTML on the other side. Granted, if you made that control channel stateful, you'd make a l…

SQL injection attacks are an excellent example where code and data are mixed. One solution is to do a lot of clever escaping of 'attackable' characters that instruct the DBMS to stop treating a character string as data and start executing things [1]. Escaping attackable characters attempts to partition data from code. This usually works but not perfectly. Or, run your data through stored procedures instead. It took m…

Hmm. I'm going to have to disagree about Stored Procedures providing security. You can do all sorts of bad things using stored procedures that may result in unintended code execution!

Perhaps the most naive example: https://pastebin.com/acQqhDvy

I think they're more useful for organization and abstraction than security. Then again, a well organized and smartly abstracted system can lead to better security!

But I think bind parameters are probably a better example of security.

Binding effectively separates the data from the logic. So you define two separate types of things, and then safely join those things together by binding them. It doesn't matter too much whether that happens in the application making a call to the database or in the database in a stored procedure. Obviously this same concept can be applied at many different points along the application stack. The analogous concept in the UI is templating. You define a template and then safely inject data into that template.

Post reply on HN