Live data from Hacker News

It’s time to kill the web app

blog.plan99.net

141–150 of 717 posts

Re: It’s time to kill the web app

#141
post #86
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.

Yeah but users don't read the HTML, the browser does, and it doesn't care that you're using ten tags for vertical spacing instead of an elegant CSS styling property. Edit : just want to make it clear that I'm trying to paraphrase here, I don't know if I agree (although I do want to point out that HN is built in this philosophy)

I’d argue that in this era of mobile devices, hard-set line breaks like
are a bad idea even in the immediate term. Regrettably, the front end isn't simple any more, and while the tooling doesn't help I think it's simply not an easy problem to fix any more.

Re: It’s time to kill the web app

#142

While i understand the article and agree with it, i love programming webapps. The combination of html/CSS is much easier (for me at least) to work with than most other rendering framework, also JavaScript while not perfect is very good for fast moving target, and with "extension" like typescript you can even manage very large application in a progressive way (you can mix js and typescript). I also work with the andro…

> The combination of html/CSS is much easier (for me at least) to work with than most other rendering framewor Html+css is not a rendering framework. Also, come back with your "much easier" when you need to do anything even remotely resembling iOS's screen transitions, animations, and capabilities for constrained layout. Even properly implementing the seemingly simple toolbar in Google Docs is an excercise in endless…

My bad, i didn't express myself, for rendering framework i mean both the language and the technology that actually "execute" them. I understand that different browser do thing different but the concept are the same.

Also i don't know ios very well, but i have implemented complex layout in both android and the html/css/js and i can say that android is MUCH more frustrating, even when we consider browser backward compatibility, especialy on the animation side (css animations were a bit hard at first, but in little time i was able to construct complex animation very quickly).

I actually have builded a toolbar like the one on google docs (which i use daily) for editing data in a timeline for appointment, which had to be compatible with IE8 and while there was a lot of pain, i was able to iterate and experimentate a lot more quickly than android, and it wasn't that bad, also in my experience when we talk about layout and user interface there is A LOT more documentation on html/css than android, and there also are more framework/library that can help you deal with browser diffrence.

Re: It’s time to kill the web app

#143

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…

I don't really understand.

You say that the web needs to be completely thrown out, yet you decided that your foray into web development should be to build a thick Javascript web application? Not some simple Flask endpoint?

Because I assume you could figure out a basic request/response server, and your issue is that you dove into something like Webpack + React + Flux + Qux + Fux + Foo.

Re: It’s time to kill the web app

#144

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…

My alarm siren went off when the commentary started critiquing the “complexity” of Google docs as compared to Windows explorer circa 1998. Complex things are often complex because the work that we do as humans is, well, complicated. A journey map painstakingly built by an epic designer and smart person at large may design the ultimate document template that addresses every need that you are aware of. Then I come alon…

Your alarm shouldn't go off, because the example is very much apt. The article compared the UI offered by both, and they are indeed directly comparable.

As for the work Google Docs do, come on, they're a glorified Markdown editor, they lose in any kind of comparison with Windows 95-era Word.

Re: It’s time to kill the web app

#145

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 still possible to write pretty secure and efficient software in modern C++. Yes it is not easy but possible.

Re: It’s time to kill the web app

#146
post #76
post #48

Earlier quoted context omitted.

> "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…

> 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 No it wouldn't. It wouldn't fix sql injection and it also wouldn't fix the path bug the op linked. The problem is not length, it is context unaware strings. The problem is our obsession with primitive types that pervade our codebases.

>The problem is not length

Oh thank God. I'm going to forward this to my wife.

Re: It’s time to kill the web app

#147

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 produ…

> In the 90s I couldn't have met with my team, with members in Moscow, California, Pennsylvania, and Texas, in any reasonable way

I remember in the mid '90s that there were a couple of applications that would allow you to do that (netmeeting from Microsoft and cooltalk from Netscape). I don't remember how easy or difficult it was to find other users though.

Re: It’s time to kill the web app

#148
The web became as popular as it did precisely because it sucks. A lot of the supporting technologies made design decisions that favored easy of use over stability and things that experienced developers like. Every argument I hear about how the web sucks basically boils down to an argument that it should be more consistent and well-designed. But most well-designed technologies fail because engineering doesn't win the day -- delivery does. I say all this even though I consider myself an engineer with a penchant for the craft of writing software. I love beautifully architected systems, but I have to sadly admit that they're often not relevant to the bottom line.

I don't think it's time now or in the near future for the web to die. Just as we often still mindlessly adhere to the 80 character limit for terminal width, even though this limit has its origins in the size of punch cards, we'll still be using traditional web stack technologies decades from now.

Re: It’s time to kill the web app

#149
post #76

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 No it wouldn't. It wouldn't fix sql injection and it also wouldn't fix the path bug the op linked. The problem is not length, it is context unaware strings. The problem is our obsession with primitive types that pervade our codebases.

>The problem is not length Oh thank God. I'm going to forward this to my wife.

"Buffer? I don't even know her!"

Ha ha. I'll get my coat.

Re: It’s time to kill the web app

#150
post #125

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 the length is not pre-defined, the input has to be parsed to look for the closing tag. That makes your code vulnerable if the input tricks it into finding the wrong closing tag. But if the length is fixed, you don't have to parse it at all. That would avoid a whole class of vulnerabilities.

True, assuming that programmers don't compute code (HTML,SQL, etc) from user input and miscompute the length of a fragment.

It would be interesting to see if this idea could work in practice.

Post reply on HN