Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

It’s time to kill the web app

blog.plan99.net

Post reply on HN
Print view View original

311–320 of 717 posts

Re: It’s time to kill the web app

#311

Post by artagnon »

SwellJoe wrote: post #12

I find this unconvincing. Every negative thing said about the web is true of every other platform, so far. It just seems to ignore how bad software has always been (on average). "Web development is slowly reinventing the 1990's." The 90s were slowly reinventing UNIX and stuff invented at Bell Labs. "Web apps are impossible to secure." Programs in the 90s were written in C and C++. C is impossible to secure. C++ is im…

Every generation of programmers _does_ learn from previous work, and every new platform starts from scratch learning the lessons, and incrementally evolves. A Hello World GUI on Windows 95 will require calling into a complex and undecipherable Win32 API; a Hello World on the web needs one simple line. Platforms do get frozen over time (like the Linux kernel), and people use it to build useful things with low effort. The Linux kernel is a result of incremental evolution: Linus proudly says that it's not designed.

There are severe shortcomings in all platforms that have aged. Why does power management in Linux suck so hard? Why can't we have networked filesystems by default (NFS is quite bad btw)? Until somewhat recently (~7 years), audio on Linux was a disaster: "Linux was never designed to do low-latency audio, or even handle multiple audio streams (anyone remember upmixing in PulseAudio?)". What the hell are UNIX sockets? Is there no modern way for desktop applications to talk to each other? (DBus was recently merged into the kernel). Why doesn't it have a native display engine? (X11?)

Today, it's more fashionable to criticize the web, since majority of the industry programmers endure it. Sure, there are some "simple" things that are just "not possible" with the web (everyone's pet peeve: centering). Yes, you lose functionality of a desktop application, but that's the whole point of a new platform: make what people really need easy, at the cost of other functionality. For an example, see how Emacs has been turned into a web app, in the form of Atom? You don't have to write hundreds of lines of arcane elisp, but you also don't get many features. Atom is a distillation of editor features that people really want.

I don't understand the criticism of transpiling everything to Js; you do, after all, compile all desktop applications to x86 assembly anyway. x86 assembly is another awful standard: it has evolved into ugliness (ARM offers some hope). Every platform was designed to start out with, and evolved into ugliness as it aged. We already have a rethink of part of the system: wasm looks quite promising, and you'll soon be able to write your Idris to run in a web browser.

Re: It’s time to kill the web app

#312

Post by nostrademons »

mwcampbell wrote: post #286
nostrademons wrote: post #255

Earlier quoted context omitted.

We don't. Learn to embrace it instead. There's a flip side to everything. In this case, if you "fixed" this problem, it would imply a steady-state world where nothing ever changed, nothing was ever replaced, and nobody could ever take action to fix the things bugging them. To me, this is the ultimate in dystopias. It's like the world in The Giver or Tuck Everlasting , far more oppressive than the knowledge that every…

Is there no possibility of steady progress without having to continually discard good solutions and reinvent things (e.g. web development catching up with the 90s)? Someone on this thread said that our field has no institutional memory. Can we at least fix that ?

You run up against Gall's Law [1]. The root cause is that many of our desires are actually contradictory, but because human attention is a tiny sliver of human experience, whenever we focus our attention on some aspect of the system we can always find something that, taken in isolation, can be improved. (I'd be really disappointed if we couldn't, actually; it'd mean we could never make progress). However, the "taken in isolation" clause is key: very often, the reason the system as a whole works is often because we compromised on the very things that annoy us.

Remember that in some areas, the web is far, far more advanced than software development was in the 90s. It's not unheard of for web companies to push a new version every day, without their customers even noticing. At my very first job in 2000, I did InstallShield packaging and final integration testing. InstallShield had a very high likelihood of screwing up other programs on the system (when was the last time Google stopped working because Hacker News screwed up the latest update?), because all it does is write to various file paths, most of which were shared amongst programs and had no ACLs. So I'd go and stick the final binary on one of a dozen VMs (virtualization was itself a huge leap forward) where we could test that everything still worked in a given configuration, and try installing over a few other applications that did similar things to make sure we weren't breaking anything else. We never did ship - we ran out of money first - but typical release cycles in that era were around 6 months (you still see this in Ubuntu releases, and that was a huge improvement on programs that came before it).

And this was still post-Internet, where you could distribute stuff on a webserver. Go back another decade and you'd be working with a publisher, cutting a master floppy disk, printing up manuals, and distributing to retail stores. You'd have one chance to get it right, and if you didn't, you went out of business.

The thing is, many of the things that made the web such a win in distribution & ubiquity are exactly the same things that this article is complaining about. Move to a binary protocol and you can't do "view source" or open a saved HTML file in a text editor to learn what the author did; programming becomes a high priesthood again. Length-prefix all elements instead of using closing tags and you can't paste in a snippet of HTML without the aid of a compiler; no more formatted text on forums, no more analytics or tracking, no more like buttons, no more ad networks (actually, I can see the appeal now ;-)). Require a compiler to author & distribute a web page and you can't get the critical mass of long-tail content that made the web popular in the first place.

You can see the appeal of all of these suggestions now, in a world where things have gotten complicated enough that only the high priesthood of JS developers can understand it anyway, and we're overrun with ads and trackers and like buttons that everyone has gotten tired of anyway, and a few big companies control most of the web anyway. But we wouldn't have gotten to that point without the content & apps created by people who got started by "view source" on a webpage.

[1] https://en.wikipedia.org/wiki/John_Gall_(author)#Gall.27s_la...

Re: It’s time to kill the web app

#313

Post by basicplus2 »

Skunkleton wrote: post #249
gens wrote: post #116

Earlier quoted context omitted.

> Programs in the 90s were written in C and C++. C is impossible to secure. C++ is impossible to secure. Back then the compilers sucked. They would take complete crap of code and still it would work. They were like browsers are today. (from my experience from going through one old MUD code) Today the song is different. Not only will the compilers warn you of many things, there's even tools for static analysis (and dy…

People always shit on C for security, perhaps rightly so. But I would like to point out that 99% of everything out there has C or C++ at its base. cpython is c, java is C++, rust is based on llvm which is C++. Yes implementing your user facing application in some non-c language may improve security, but you are still depending on C when you do so. So is C the problem, or is it modern CPU architecture? C has stuck aro…

D

Re: It’s time to kill the web app

#314

Post by ZenoArrow »

bsder wrote: post #189
ZenoArrow wrote: post #114

Earlier quoted context omitted.

> "the microsoft office suite for instance slows down every generation despite only having minor improvements and not actually being that different now than from 95" I can't comment on most of the Office suite, but Excel evolved quite a bit since 95. Tables, PowerBI, Apps for Office, etc... If your needs are basic enough then even VisiCalc will do the job, but new features do make an impact for more demanding users.

Power users are the vector to spread Microsoft-only spreadsheet viruses. This is what gets lots on most people. The power users create some "nifty" spreadsheet that runs some "important" piece of a business. That "nifty" spreadsheet now requires Microsoft Excel and forces everybody in the company to have a copy if they want access to it.

Those power users are covering for the lack of resources and/or knowledge in a company's IT department. Excel may not be the best tool for long tail apps, but there's no arguing with its ability to quickly build useful tools. The power user that you see as spreading a virus is essentially successful as they can innovate more quickly than anyone else in the company. If open source tools gave this power user the same ability to rapidly innovate, then they should be made available to them (along with training on how to use this software).

Re: It’s time to kill the web app

#315

Post by zaroth »

an_account wrote: post #121
SwellJoe wrote: post #62

Earlier quoted context omitted.

"Most injection attacks are due to this; if html used length-prefixed tags rather than open/close tags most injection attacks would go away immediately." How so? If you allow the user to send arbitrary data, and your handling of that data is where the problem lies, it isn't going to matter whether the client sends a length-prefixed piece of data. You still have to sanitize that data. HTML, and whether it uses closing…

If you can say, “the next 450 characters are plain text and should be rendered as such”, then even if the text includes script tags (or whatever), they won’t be parsed or executed.

There is a .innerText property which works perfectly fine for this if you want to ship your content inside JSON and then plug it in...

Re: It’s time to kill the web app

#316

Post by zAy0LfpBZLC8mAC »

> The fix: All buffers should be length prefixed from database, to frontend server, to user interface.

If you think that that is a solution to anything, you must be living in a universe where ASN.1 implementations have not ever had bugs, in particular they must never have had any vulnerabilities.

It's certainly not the universe that I live in.

In that same universe, packet sniffers/protocol disectors probably also never had any vulnerabilities due to blindly trusting length values?

Re: It’s time to kill the web app

#317

Post by sebpmtl »

open-source-ux wrote: post #169
bitexploder wrote: post #157

Earlier quoted context omitted.

If you want to write web apps, save the HTML for last. When you are writing apps for yourself you write just what you need. That is what I am saying. Functional HTML first. It's not hard to write plain looking but very good UX. I think we are agreeing. I meant write stuff that works but is not fancy and avoid the big JS frameworks.

Yes, I agree. Sometimes (maybe often?) plain HTML and CSS with a little bit of Javascript (and server-side logic) works perfectly fine for many "web apps". It can even be faster (and simpler) than downloading all the app logic and a fat Javascript library to the client.

That's why It's a good thing to develop mobile-first, you tend to keep things more minimal.

Re: It’s time to kill the web app

#319

Post by armitron »

Devid2014 wrote: post #145
SwellJoe wrote: post #12

I find this unconvincing. Every negative thing said about the web is true of every other platform, so far. It just seems to ignore how bad software has always been (on average). "Web development is slowly reinventing the 1990's." The 90s were slowly reinventing UNIX and stuff invented at Bell Labs. "Web apps are impossible to secure." Programs in the 90s were written in C and C++. C is impossible to secure. C++ is im…

> Programs in the 90s were written in C and C++. C is impossible to secure. C++ is impossible to secure. You know that most today OS are written in C or C++ ? Also many higher level languages are it self written in C or C++? Write secure applications is hard and need a lot of discipline and knowledge that most developers simple do not have. Better tools can and need to help here as well as better languages. But it is…

Then prove it, list substantial codebases written in C++ that you deem secure. You'll find that it's not easy to do.
Post reply on HN