Live data from Hacker News

It’s time to kill the web app

blog.plan99.net

601–610 of 717 posts

Re: It’s time to kill the web app

#601
post #466
post #350

Earlier quoted context omitted.

Those communities are all very niche, and in fact part of their brand and image is in their design. Even though they are less flashy, that is the point. Try to convince the owner of a clothing ecommerce site that their store should look like a 4chan bulletin board while trying to sell high priced garments to the public, or that the Coke website can't have a vibrant design in line with the rest of their branding.

I don't understand one point here - why wouldn't Coke be able to have vibrancy? Animated .GIF images have worked very reliably for web layouts since... forever; and I don't think anyone's going to start calling for everything to be pastels online or in a fixed color scheme. I don't feel that Reddit is by any means 'niche', either. And of course a clothing store (which is an e-commerce product) should look different f…

I am a huge proponent of keeping it simple for websites. If you can achieve the same branding with less tooling then that is ace, and it is what I try to do. Less complexity means it's more maintainable and normally quicker to build.

But it will need to be the same experience that the client asked for. Coke is never going to ask you for a react website with webpack tooling and a lambda backend, they are going to come to you with some grand vision of an application that their marketing team imagined in the shower months ago and has been workshopped into a mess. You may or may not be able to deliver that with simple HTML and CSS.

I am also keen for the web to move toward some kind of stability in technology as well, the churn and wheel reinvention factory that we currently have is creating a bit of a mess but I don't think it's worth throwing the web away just yet.

Re: It’s time to kill the web app

#602
post #106

Earlier quoted context omitted.

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

Agreed, I learned Elm a year ago and haven’t looked back. Love being able to dismiss all other frontend web talk without a second thought.

Re: It’s time to kill the web app

#603
post #556

Earlier quoted context omitted.

The security aspect was an interesting part of this piece, because one of the main reasons webapps took over from Windows apps is because they were perceived as more secure. I could disable ActiveX and Java and be reasonably confident that visiting a webpage would not pwn my computer, which I certainly couldn't do when downloading software from the Internet. And then a major reason mobile apps took over from webapps…

> I could disable ActiveX and Java and be reasonably confident that visiting a webpage would not pwn my computer Unfortunately, this is not entirely true. There were bugs in image processing, PDF processing (some browsers would load it without user prompting), Flash, video decoders, etc. IIRC even in JS engines, though those are more rare. Of course, you could go text-only, but then you couldn't properly access about…

The Javascript security model breaks down in the case of file:///, no overflows are required. The security you get today is more flimsy than you probably think. And it used to be far worse.

Re: It’s time to kill the web app

#604

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…

As an iOS developer, I would say state of web development is not true for iOS. Sure it is slowly evolved to the current state but the framework much more thought out than their web counter part.

"As an iOS developer" is another way of saying "I can't see past the walls of Apple's walled garden".

Seriously, the reactive frameworks (any really: React/VueJS/Preact/...) used in tandem with a separate state container (Redux, Vuex...) is a much better "thought out" approach to application programming than anything in the Cocoa/Swift world.

Re: It’s time to kill the web app

#605

Earlier quoted context omitted.

> A programmer thinks of all the ways that a program could fuck up your computer; it's a large part of our job description. The average person is terrible at envisioning things that don't exist or contemplating the consequences of hypotheticals that haven't happened. I'm not sure programmers are much better. There's a long history of security vulnerabilities being reinvented over and over. Like CSRF is simply an inst…

> And blaming this on the market is a cheap attempt to dodge responsibility. How many hacks, data breaches, and privacy violations does it take for consumers to start giving a shit? Also, any programmer will tell you that just because an issue is tagged "security" doesn't mean it will make it into the sprint. Programmers rarely get to set priorities.

> How many hacks, data breaches, and privacy violations does it take for consumers to start giving a shit?

There's a quote by Douglas Adams pops up in my mind whenever the subject comes up:

> Human beings, who are almost unique in having the ability to learn from the experience of others, are also remarkable for their apparent disinclination to do so.

This is the only explanation there can be for this. Every time there's a breach somewhere (of which there obviously are plenty), there's a big outrage. But those who should go "oh, could that happen to us, too?" choose to ignore it, usually with hand-waving explications of how the other guys were obvious idiots and why the whole thing doesn't apply to them.

This obviously goes for consumers and producers.

Re: It’s time to kill the web app

#606

Earlier quoted context omitted.

I really wish it had a format for dates.

ISO 8601 [0] defines the standard for data elements and interchange formats. It's widely supported on all major programming languages. The only issue is having to manually convert the string. [0] https://en.wikipedia.org/wiki/ISO_8601

It's not defined as the standard date representation for JSON, nor is anything else, so every library does its own incompatible thing.

Re: It’s time to kill the web app

#607

Earlier quoted context omitted.

I really wish it had a format for dates.

I use just a "time" number for it (but I also do not have dates before 1970)

Well the fact that you and the other guy offered different "standards" to use is kind of exactly my point.

Re: It’s time to kill the web app

#608

Earlier quoted context omitted.

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.

Windows 95-era Word didn’t have to handle real-time collaboration over the Web between an arbitrary number of users.

Real time collaboration is an awesome feature and essentially what justifies Google Docs' existence, as it's behind Word in practically every other area (though I find Sheets more intuitive than Excel, that might just be familiarity).

The technology to do RTC is not particularly resource intensive on the client side. Nor is it web specific: the native Android versions of Google Docs don't use the web but they do support RTC.

RTC is enabled by an algorithm called "operational transform". It's a very clever algorithm that is rather tricky to implement properly, but it doesn't involve loading huge datasets or solving vast numbers of equations. It's ultimately still just about manipulating text. You could have implemented the client side part of it on Windows 95 without trouble, I'd think. At least I can't see any obvious problems with doing so, assuming a decent Windows 95 machine like one with 8 or 16mb of RAM.

OT does, however, require the entire app to be built around the concept. You can't easily retrofit it to an existing editor.

The reason Word 95 didn't have Docs style realtime editing is simply because back then networks were kind of rare, slow, crappy and word processor designers didn't know about the OT algorithm back then because it was still being researched by academia.

The real question is - if we had a better client side platform on laptops and desktops, one that supported some of the best features of the web without the rest, would Docs RTC still be possible? Surely yes!

Re: It’s time to kill the web app

#609

Earlier quoted context omitted.

"Most web apps are built in languages that don't have buffer overrun problems." You misunderstood the author's point. Things like SQL injection are really equivalent to buffer overflow attacks -- data creeping into the code because of poor bounds checking.

But SQL injection isn't a thing unique to the web right? Like, SQL injection is totally a thing with c/c++ as well. Maybe focus on one problem at a time.

SQL injection is to do with SQL, a text based protocol for expressing commands to a server. Like all text based protocols trying to combine it with user-provided data immediately takes you into a world of peculiar escaping rules, magic quotes and constant security failures.

The fix for SQL injection is to work with binary APIs and protocols more. Parameterised queries are the smallest step to that world, where the user-supplied data rides alongside the query itself in separated length-checked buffers (well, assuming you're not writing buggy C - let's presume modern bounds checking languages here). They aren't combined back into text, instead the database engine itself knows how to combine them when it converts the SQL to its own internal binary in-memory representation, as IR objects.

Another fix is to move entirely to the world of type safe, bounds checked APIs via an ORM. But then you pay the cost of the impedance mismatch between the object and relational realms, which isn't great. I will provide a solution for this in part II.

Re: It’s time to kill the web app

#610
post #601
post #466

Earlier quoted context omitted.

I don't understand one point here - why wouldn't Coke be able to have vibrancy? Animated .GIF images have worked very reliably for web layouts since... forever; and I don't think anyone's going to start calling for everything to be pastels online or in a fixed color scheme. I don't feel that Reddit is by any means 'niche', either. And of course a clothing store (which is an e-commerce product) should look different f…

I am a huge proponent of keeping it simple for websites. If you can achieve the same branding with less tooling then that is ace, and it is what I try to do. Less complexity means it's more maintainable and normally quicker to build. But it will need to be the same experience that the client asked for. Coke is never going to ask you for a react website with webpack tooling and a lambda backend, they are going to come…

My response to "grand vision" projects is to say, "work up an actual spec of what's necessary, and I'll respond based on what's technically feasible." I find that when they finally get their heads out of their entrails, most needs are very simple. Animation can be done in .gif, static images can be supported by imagemaps and tables.
Post reply on HN