Live data from Hacker News

It’s time to kill the web app

blog.plan99.net

161–170 of 717 posts

Re: It’s time to kill the web app

#161
post #90
post #35

Earlier quoted context omitted.

> 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.

Maybe what parent meant to suggest is to wait with "proper frontend" and keep ugly quick&dirty minimal HTML until the whole software/app/system/server/set-of-services/whatever is "done", and just works . Because once you distract yourself with making it pretty, it's a rabbit-hole of ever-new, ever-different, ever-more-promising paradigms to switch to and fro. But not sure if that was his idea here..

Yes. Write simple but correct HTML. Don't make it look nice. Make the UX good. Don't spend time with crazy JS frameworks. Simple forms. Use properties for screen readers and usability if you must. When you are learning avoid getting sucked into JS and CSS holes.

Re: It’s time to kill the web app

#162
post #48

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…

> "Web development is slowly reinventing the 1990's." > The 90s were slowly reinventing UNIX and stuff invented at Bell Labs. Yes, this reminds me of: "Wasn't all this done years ago at Xerox PARC? (No one remembers what was really done at PARC, but everyone else will assume you remember something they don't.)" [1] > "Buffers that don’t specify their length" > Is this really a common problem in web apps? Most web app…

> if html used length-prefixed tags rather than open/close tags most injection attacks would go away immediately.

That's not really the problem. The problem is there is no distinction between data and control leading to everything coming to you in one binary stream. If the control aspect would be out-of-band then the problem would really go away.

Length prefixes will just turn into one more thing to overwrite or intercept and change. That's much harder to do when you can't get at the control channel but just at the data channel. Many old school protocols worked like this.

Re: It’s time to kill the web app

#163
post #48

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…

> "Web development is slowly reinventing the 1990's." > The 90s were slowly reinventing UNIX and stuff invented at Bell Labs. Yes, this reminds me of: "Wasn't all this done years ago at Xerox PARC? (No one remembers what was really done at PARC, but everyone else will assume you remember something they don't.)" [1] > "Buffers that don’t specify their length" > Is this really a common problem in web apps? Most web app…

Even when the sender tells you the length of the data to expect the receiver still needs to read every thing that is sent?

Or were senders always going to send true values for length and data?

Really, you can't trust any sender, so the data should be validated anyway.

There's been known attacks where a sender says here's 400 bytes and the receiver stupidly trusted that length specifier, and the sender's sends more (or less) crafted bytes and BOOM!

Known good data start and end specifiers, which HTML has, seems a good answer when dealing with untrusted senders (read:everyone)

Re: It’s time to kill the web app

#164

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.

This seems like an argument for strong types. Which is reasonable. But, one could do that with closing tags, too. We already know that relying on a programmer to specify the length of data is prone to bugs (C/C++). And, you can't trust the client to specify the length of data.

I feel like this is conflating two different problems and potential solutions.

I'm not saying injection attacks aren't real. I'm saying that whether HTML uses closing tags or not is orthogonal to the solution. But, again, maybe I'm missing something obvious here. I just don't see how what you're suggesting can be done without types and I don't see how types require prefixing data size in order to work.

Re: It’s time to kill the web app

#165
post #35

Earlier quoted context omitted.

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.

When you are learning spending time on the front end is a terrible time investment. Your first web apps are for yourself usually. This is exactly why the grandparent gets frustrated. Make an ugly app that works first.

Re: It’s time to kill the web app

#166

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 meant that way. What better way to get rid of annoying independent programmers like you (and me) than by setting things up in such a way that you need a large company to make any headway at all? That's just another form of lock-in and a way to deepen the moat for upstarts who are historically the most dangerous types for established players.

Re: It’s time to kill the web app

#168

Seriously? the web app is the most ubiquitous and flexible app on the planet; adapt or die.

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.

Re: It’s time to kill the web app

#169

Earlier quoted context omitted.

> Write the ugliest HTML you want Writing correct HTML helps people using screen readers because they can navigate a page using the descriptive HTML elements. In fact, writing correct HTML is probably the simplest and easiest thing to do when it comes to creating a web page. It's CSS that's needlessly complicated and unpredictable.

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.
Post reply on HN