Live data from Hacker News

It’s time to kill the web app

blog.plan99.net

31–40 of 717 posts

Re: It’s time to kill the web app

#31

It's probably not realistic, but I would love to see the web be completely thrown out and replaced with something reasonable. I write a decent amount of native code. I write Rust, C, and x64 assembly. I think I'm pretty good at this stuff. But the web is too much for me. Any time I think I'd like to do something with the web and sit down to learn, it's completely overwhelming. I've never been able to put together a c…

"Any time I think I'd like to do something with the web and sit down to learn, it's completely overwhelming. I've never been able to put together a coherent mental model of the architecture of a web application or figure out what the best practices are for web development."

If it makes you feel any better, that's because there isn't a coherent mental model. If you've ever heard of the ORM/Relational impedance mismatch, it's got nothing on the set of impedance mismatches between the way servers like to work, the HTTP protocol (and its still very page-based orientation in a world of streams), the browser's DOM model, and how Javascript works, especially if you want to get excellent performance out of it.

It is my opinion that this is why you see so much churn in the web world; the continuous iterations on client-side frameworks, server-side frameworks, this Javascript DOM library, that Javascript DOM library, now an integrated framework, now recommending assembling your own from bits and pieces... it's all a reflection of the fact that none of these pieces particularly work all that well together in the way we'd really like them to. There's a ton of possibilities, all of them frankly pretty bad in most ways but good for this one use case, but a different use case for each tech, and that's a recipe for a lot of churn.

My recommendation to anyone getting into this world is A: learn the basics of HTTP B: learn the basics of HTML C: clock some time with Javascript's basic DOM interface and maybe jQuery and then D: relax about the whole thing, unless you really think you're going to build an app that scales up to the tens of thousands of simultaneous users. The truth is that when it comes down to it there are still plenty of applications you can successfully build and deploy using completely 2005 technologies... and the dirty secret truth is that you may well beat someone to market who is over-invested in staying Up To Date and constantly throwing away all their skills.

(You will not beat to market someone who is judiciously staying up to date, and carefully picking and choosing what modern tech to learn and deploy. But you still probably won't be that far behind them, either. And that is not the person who is actually freaking everyone out about the web; it's the guy vigorously selling Vue.js or whatever modern thing as the hot new thing and that all previous JS libraries are now trash that should be used by nobody, when six months ago they were saying the same thing about something else.)

Re: It’s time to kill the web app

#32

Even though it's a bit forced, I agree that the whole mainstream computer field as a weird non ROI. Machines 10000x faster, personal value/productivity: flat or below.

How do you measure that, though?

It seems like you have to ignore all value derived from networks in order to come to the conclusion that software is no more powerful than in the 90s.

In the 90s I couldn't have met with my team, with members in Moscow, California, Pennsylvania, and Texas, in any reasonable way...today I can chat, including video and sound, on a whim!

Managing source code today is massively more productive than in the 90s. CVS (or, heavens forbid, RCS) on a central server was how it was done back then, if you had revision control, at all. It's not merely a better revision control system (git), it's the web-based infrastructure around it (github/gitlab/web-based CI/whatever). That wouldn't be possible on any platform that's less connected and less widely available than the web.

The rise of package managers is another massive productivity booster that maybe goes unheeded (we all love them, but I think their productivity value is wildly underestimated...how else can you add 100,000 lines of code, that probably works, in a couple of minutes, and reliably allow every member of your team to do the same?). Web technologies have enabled that. There's a reason npm has the largest package selection the world has ever seen, and I think it's the massive interconnectivity of the web platform. (This feels sort of vaguely defined, I guess...but, there is a magic to the web platform.)

There's so many areas where we're more productive today because of the network effects of the web as a platform. Also, because the web is universal, I don't have to use Windows, ever. Everything I ever want to do has a Linux version. Anything that falls short of complete platform independence is probably a step backward, IMHO, even if it has other benefits like smaller/faster binary builds.

Also...WebAssembly is coming. We're going to see a fast/efficient web, long before a new platform could possibly be delivered.

Re: It’s time to kill the web app

#33
I disagree.

- Web apps remove the need for installing an application. This alone has multiple positive implications, such as lowering the entry barrier for usage.

- Most of the time you can use them from any operating system.

- Security-wise, locally installed apps are not more secure. A locally running app if anything gives a larger attack surface to the end user.

- The level of security major browsers have is not within an average business budget.

Finally, the most important point:

Security is a 2 way street. Just like you can attack software installed in your computer, the software itself can as well be malicious and attack you. Web browsers provide guarantees on what a web application can do and what they cannot. Without these guarantees, it would be much harder to trust an application. Mobile operating systems try to solve this problem with permissions, and it has been rather effective, but not all people pay attention to them. With desktop apps you are largely on your own.

Re: It’s time to kill the web app

#35

It's probably not realistic, but I would love to see the web be completely thrown out and replaced with something reasonable. I write a decent amount of native code. I write Rust, C, and x64 assembly. I think I'm pretty good at this stuff. But the web is too much for me. Any time I think I'd like to do something with the web and sit down to learn, it's completely overwhelming. I've never been able to put together a c…

That's cause the web is full of hype. Try Python Flask. A three line Python function and you are going. No magic. Just request and response. It is easy. Bang out a model class and read the SQLAlchemy tutorial. The web and RDBMS with just enough magic. Screw HTML front ends. Write the ugliest HTML you want. Never spend time in HTML. Make your app / idea work. Get your data right. Front ends and modern front end tech s…

> Write the ugliest HTML you want. Never spend time in HTML. Make your app / idea work.

Huh? That HTML is what your users will spend 90% of their time interacting with. They won't care one bit what RDBMS you're using.

Front end development is deeply frustrating but it's also incredibly important.

Re: It’s time to kill the web app

#36
Excellent article. It's time to scream aloud that the emperor has no clothes. This farce has gone too far:

Most of the facilites for implementing a web app started as a quick and dirty hack, creating abuse of HTTP Forms, DOM manipulation, etc. Aided by Javascript, itself a hack (the creator was under heavy time pressure to deliver a language.)

We've built a whole empire using these flawed pieces.

I'm bookmarking this article.

Re: It’s time to kill the web app

#37

the biggest security blunder of the web platform is allowing third party domains to inject code into https pages, which completely violates the trust that https is meant to establish. and it's here to stay, folks! because the entire trillion-dollar ad industry is built upon it, vacuuming up data about users across the internet. a huge amount of security and privacy issues would vanish overnight simply by requiring sa…

I agree and disagree. From the perspective of anyone making a web site it's very easy to secure yourself against JS running on a third party domain: don't load any.

That sites do load these scripts says a lot more about their priorities and the state of online advertising than it does about browsers themselves.

Re: It’s time to kill the web app

#38
> First, use an XSRF token as discussed earlier to make sure that JSON results containing confidential data are only returned to your own pages.

Is this necessary for GET requests that return JSON? You need to include a XSRF token in the request headers?

Re: It’s time to kill the web app

#39
>> We desperately need a way of conveniently distributing sandboxed, secure, auto-updating apps to desktops and laptops.

What's the proposal?

* App stores controlled by juggernaut companies, doing the app-screening?

* Signing web apps bu an authority?

* Writing in "safe" languages in java/rust/..?

* Java applets?

* Adobe Flash? Silverlight?

* Uglified, minimized encrypted JS code?

* or Win95 style self-extracting installers for downloaded apps, installed by users with no package management?

* Debian style package managers?

Re: It’s time to kill the web app

#40
post #37

the biggest security blunder of the web platform is allowing third party domains to inject code into https pages, which completely violates the trust that https is meant to establish. and it's here to stay, folks! because the entire trillion-dollar ad industry is built upon it, vacuuming up data about users across the internet. a huge amount of security and privacy issues would vanish overnight simply by requiring sa…

I agree and disagree. From the perspective of anyone making a web site it's very easy to secure yourself against JS running on a third party domain: don't load any. That sites do load these scripts says a lot more about their priorities and the state of online advertising than it does about browsers themselves.

i dont expect site authors to give 2 shits about security when the alternative is ad revenue. that's assuming they even understand the security/privacy implications of spending 5 seconds to add that one-liner social sharing widget.

75% of web devs wont bother to consider it and the other 24% wont care.

it's the job of browser vendors to provide saftey for the masses. of course the giant conflic of interest here is that most browser vendors get a cut of the ad revenue.

there's a massive need for a payment platform that allows for browsing ad-free but still paying directly for content as-you-go. i think Brave is trying to do this.

cryptocurrency may provide the privacy protections for this type of arrangement.

Post reply on HN