This article is so naive. It completely negates all the benefits of the open web while presenting problems along with non-sensical "fixes"...
I mean, he worked at Google for 8 years, so he probably picked up some of their attitude. cough AMP cough
It’s time to kill the web app
101–110 of 717 posts
Re: It’s time to kill the web app
#102This reads like an article about web applications written by somebody who doesn't have any meaningful amount of experience writing web applications (which I've just seen he admits further down in the comments). The number of false statements and false assumptions in just the first section is enough to make it hard for me to continue reading, since it's supposedly the foundation for the rest of the suggestions. > Web…
> Web components are a failed/failing/doomed (IMO) proposed standard and have nothing to do with the common UI component frameworks that exist today. The design of web components is about building component object hierarchies, and is doomed to fail (IMO) in a markup language that excels at composition.
1. Exactly
2. Instead of building a set of native (to the platform) common UI elements w3c ended up ckreating an incomplete low-level API for something, no one knows what exactly.
3. Existing UI frameworks re-invent a huge amount of things, poorly and inconsistently.
Re: It’s time to kill the web app
#103Said the author who wrote the post inside a rich text edition app, a web app, which happen to be this thing called Medium. Oh the irony!
Please read Medium's own posts on how they implemented this capability and the pain they went through implementing it.
Re: It’s time to kill the web app
#104Earlier 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.
SQL injection is not a web problem. If you create SQL queries based on any untrusted (e.g. user) input on any platform, you have to escape/explicitly type your input.
Injection in general is simply a trust problem. If you can trust all inputs fully (hint: you can't, because nobody can), then you will never have an injection attack.
Re: It’s time to kill the web app
#105It'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 mismatc…
A lot of the churn is because the web is so young as an application platform. It’s been less than 20years since GMail which was probably the first thing that even approximated an application on the web. Chrome was released in 2008 less than 10years ago, and it was the first time the web had a runtime engine which was perform at enough to even build an app.
Re: It’s time to kill the web app
#106I sympathize with the sentiment, but the web app only sucks if you're using the stuff that sucks. Like any technology with decades of evolution it has a thick sediment of peat. Half of Javascript, half of Windows, even half of *nix is garbage you should never use, but it's all there because old things would stop working without it. It's just that the web has a very low barrier to entry and very high reach, so the com…
> but the web app only sucks if you're using the stuff that sucks. Please show me anything that doesn't suck on the web. And yes, I've been doing web development for close to 17 years now. There's almost nothing that doesn't suck on the web. The languages, the tooling, the platform - you name it. It is good for one thing, and one thing only: displaying single-page interlinked documents with little to no embedded medi…
I have been using elm for some time now, and it's the first time I feel I am using a non broken tool.
Re: It’s time to kill the web app
#107Earlier 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 point is that if you know the length of some data up-front before starting to parse it, you don't have to inspect the data in any way to see when it ends. This means that you don't need to know what the SQL injection looks like and protect against it, or what JS looks like to sanitise your inputs – the problem does go away to a large extent.
Re: It’s time to kill the web app
#108It'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.
For what its worth, any time I go to sit down and learn iOS development I find it completely overwhelming.
Just because you're a fancy smart assembly developer doesn't mean you'll immediately be able to master everything you encounter.
Re: It’s time to kill the web app
#109While 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 frustration.
Re: It’s time to kill the web app
#110Earlier quoted context omitted.
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…
"mainstream computer" < I was talking about the average desktop use, not distributed codebases
Sure, I was speaking directly to what I know...but, are distributed docs in Google Docs not more productive than passing around a Word doc with annotations? Is banking, accounting, trading stocks, bill payments, buying and selling nearly any product, not more productive today due to the same forces? We (people in tech) are just at the leading edge of it...but, it impacts everyone.
But, I would argue that the web platform has produced a bigger productivity boost (in terms of output per unit of time) than any other single paradigm shift in computing history. Who cares if typing is a little more sluggish than the native app if you don't have to email the resulting document to everyone on the team and then converge edits at the end of the editing process?