Live data from Hacker News

It’s time to kill the web app

blog.plan99.net

261–270 of 717 posts

Re: It’s time to kill the web app

#261

This article is so naive. It completely negates all the benefits of the open web while presenting problems along with non-sensical "fixes"...

For me the open web died when EME won. Someone should build an application platform from scratch instead of wasting more time on this crappy document platform with application capabilities.

Re: It’s time to kill the web app

#262
post #233

Earlier quoted context omitted.

I just find the way DOM/CSS does layout and styling to be completely convoluted and crazy compared to any desktop toolkit since 1990. Center anything either vertically or horizontally - that cannot require me to google and most importantly cannot have multiple different solutions . Simple things should not just have simple solutions, they should have one simple solution. Memory-unsafe programs on the desktop should g…

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 problem is that if you present an average web user with the interface you can design (quickly and efficiently) in VB6, they'll spit in your face.

Much of the complexity of web design is not in the tools; it's in the fact that users don't expect a standard whatsoever, they just expect their UIs to be as slick and customly designed as magazines. If every website was written using the same standard, predefined set of widgets and components, the complexity would disappear.

Re: It’s time to kill the web app

#263
post #233

Earlier quoted context omitted.

I just find the way DOM/CSS does layout and styling to be completely convoluted and crazy compared to any desktop toolkit since 1990. Center anything either vertically or horizontally - that cannot require me to google and most importantly cannot have multiple different solutions . Simple things should not just have simple solutions, they should have one simple solution. Memory-unsafe programs on the desktop should g…

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.

MS really had rapid GUI development absolutely nailed in the late 90s. For some reason we forgot all that.

Re: It’s time to kill the web app

#264

Earlier quoted context omitted.

Yep, also on speed: it seems to me that 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. The nature of developers is that they will use whatever resources that they have. Faster computers don't necessarily mean faster applications but faster software development cycles from bigger teams with less need for…

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

Visicalc? How about a web app - Google sheets? It gains features every day and it's imminently accessible.

Numerous similar apps depending on what online platform you prefer.

Re: It’s time to kill the web app

#265

I don't get the section on JSON, which seems to assert that XML is more secure than JSON. It does this by linking to a Wikipedia page that includes the security consideration that you shouldn't call eval on JSON. True, but at least that's a tractable problem. Your linter can check for code that calls eval. In contrast, there are plenty of XML attacks (DOS with billions of laughs, entity references), and parsing XML i…

"If you want to rag on JSON, that's fine. It's not a great format" JSON is simple and powerfull. It's success justifies it, to call it a great format, I think. But I am curious, what whould be a great format, in your opinion?

JSON gets the most important thing right: it's simpler than XML. I probably should have rephrased my comment. I literally mean that it's a decent format, but not a great one.

One issue is that it's surprisingly poorly specified: http://seriot.ch/parsing_json.php.

As a data-interchange format, it lacks first class dates/timestamps, the issues about specification are a pain when dealing with numbers (depending on language, you may not be able to use the full range of 64 bit ints), and has no builtin concept of schemas. That said, I'm not sure what I'd recommend above JSON, though you clearly wouldn't use it for really high performance servers.

It's also used as a configuration language, where more issues surface. It doesn't accept trailing commas or comments (I can see the argument for requiring all keys to be quoted, but that's a pain to write as well). For configuration, I think I prefer TOML to JSON. Dhall looks cool, but I've never used it.

Re: It’s time to kill the web app

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

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

No that's only half the solution, the other (much harder) half is to ensure you have no XSS. The GP's point was if they hadn't allowed cross-origin scripting it would have had big security benefits.

Re: It’s time to kill the web app

#267
post #240

Earlier quoted context omitted.

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…

For the sake of creativity, suppose browsers were the wrong direction to take for web exploration. What do we do now? The same idea may be applied to an operating system's ability to allow a user to operate on their machine. Edit: It would be useful to consider why the need for a universal interface to the internet was originally sought out.

Telnet? That's the alternative I can remember.

Re: It’s time to kill the web app

#269

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…

> Most web apps are built in languages that don't have buffer overrun problems.

The author is using "buffer" in a different sense than you are. You're thinking of a malloc'd buffer. The author is using "buffer" more abstractly, to refer to a data segment, such as a JSON or HTML string, or a string of encoded form data. His point is that that latter type of "buffer" has no declared length, and needs to be parsed in order to determine where it ends, and that as a result it is subject to problems that one can term "buffer overrun" by analogy with the traditional C scenario in which one obtains a pointer to some memory that you should not have access to.

Re: It’s time to kill the web app

#270
I rather think, It's time, to completley ignore sensationalistic rant's like this one.

First of, killing a technology does not solve anything. It just means less options. So do propose your better solution (and build it) - then we can talk about killing the current thing.

But the way it is today, the web works.

Definitely not flawless and in large parts really ugly (just browsing with open dev-tools is horrifying, when you see all the errors and warnings thrown at you) - but it is big and reduntant enough, that you can mostly choose only the nice parts.

XMLHttpRequest is ugly? (I allways thought so) Well, there are WebSockets now.

Javascript lacks typesupport etc? - Use Typescript

The whole DOM and *script languages in general are ugly? Skip it all and use only WebGL and Wasm.

And your app will still run allmost everywhere.

That's the power of the web - that's why it became so important. It just works.

And it is very easy to start doing it ... so many people did this, who do not have a CS background. And obviously they made horrible things from an academic point of view. But things still kind of worked for them.

And security ... well, so far I have not yet heard of a save language/OS/Plattform where people can work productivly without years of studying the theoretic backgrounds.

So in general yes, I am very open for better designed alternatives. In fact I am looking for one since I started web-developement, but not so much for angry hyperbolic rants like this one. They are not helpful.

Post reply on HN