Hacker News Reader

Comment by nkoren | Hacker News Reader

The web no longer consists of just static web pages and form data.

I build complex web applications, which are stateful in many ways that don't involve forms (and involve things like websocket connections, etc). There's no way that the browser could possibly recreate that state by going forward.

So web apps of any complexity must necessarily intercept the delete key and break its functionality. And to the extent that the web increasingly consists of such apps, it means that "delete to go back" has long since being a standard feature that users can count on. That's just a fact on the ground. Time to remove the expectation entirely.

View on HN

Finally someone brought up the fact that web does not consist of static classic HTML forms only, HOWEVER I still think Chrome could just restore those that ARE static, and as for the forms that are rendered using client-side templates in single-page apps, their creators should store them as they're being filled, just like Gmail or Google Docs store what you're typing without you having to save it manually.

I incline to believe that users that were filling out long forms (and subsequently complaining about losing data because of hitting backspace) were filling out classic old-school static HTML forms, where automatic form restore by Chrome would certainly help.

I agree that automatic form restoration would be very helpful, but there's a huge space between classic HTML forms (where this is "easy") and single-page apps (where nobody really expects it to happen).

That space is where complex, dependent-on-javascript-for-no-good-reason forms live. The kind often encountered when dealing with financial & public institutions. It's unlikely that automatic form restore is going to work for a lot of these (especially multi-step wizards & the like) so preventing an extremely common accident seems extremely prudent to me.

> There's no way that the browser could possibly recreate that state by going forward.

Of course there is—just don't delete anything immediately. All your state stays there like it's in its own (hidden) tab and gets lazily garbage collected "some time" later. If the user navigates back, there's nothing to rebuild as everything is still sitting there intact.

While that would work, this seems like the path to "Firefox is too heavy and uses lots of memory."

I don't know how Safari does it, but it works, is incredibly fast, and eats much less memory than Chrome. (My browsing habits suggest Safari is about 30-40% cheaper in terms of memory, but that's anecdata so truck loads of salt required.)

In any event, there are way too many replies to keep count of in this thread, but all I can say is that however Safari does it – it just works(tm). Accidental backspace has literally never been an issue for me since they implemented this. There are convincing arguments why backspace as a short cut is a bad idea to begin with, but old habits die hard, and I for one am very happy that Safari makes this work.

People would quickly come to depend on their data not being lost when they leave a page, and then be very unhappy when sometimes it is lost.

What do you do about WebSocket connections or hanging GETs? Do you lie to the page about whether its still being rendered visibly? Etc etc.

This all seems terribly expensive relative to removing a hotkey used by fewer than 1% of users.

Complex web applications that have less functionality than what you are trying to replace.

Great work!!!

> that have less functionality than what you are trying to replace

How so? Can you elaborate?

Last night I watched 19 engineers use my application to work collaboratively, in real-time, on a single canvas, to design a transport network for a city. That kind of functionality has never existed before, anywhere, and is a damned sight more important than preserving the idiotic "delete === go back" keybinding that 99% of the population doesn't even know exists and only ever triggers accidentally.

Reply on news.ycombinator.com