Hacker News Reader

Comment by csirac2 | Hacker News Reader

Around 2012 I worked with a team migrating some content from a very large static HTML site dating back to 1992. We scoffed at the awful ad-hoc nature of it all, just a pile of static hand-coded HTML pages.

But the 2002-2005 stuff had aged much worse. At some point there was fancy site generator that had used javascript for everything, and the javascript apparently only worked properly in IE6. So most of the navigation was busted in a modern browser, and needed special scrapers to parse out what should have been plain old <a href...> tags.

Now, I regularly think back to that crusty old HTML3 static site that had sat there for 15-20 years and think: I wonder if my AngularJS/D3.js/jqGrid/etc. single-page app will even load in a browser 20 years from now, let alone perform as originally intended...

View on HN

It's not just HTML. I think any proprietary standard runs the risk.

We've been burned at my work by old word and word perfect documents from early 90's refusing to render properly in new versions of office. I think they tried about three recent versions of office before they gave up and resorted to scanning in hard copies as PDF's to recover some documents.

Access databases are also notorious for this problem. A lot of business apps were written with Access in the mid 90's and it has now become too expensive/time consuming to migrate them off of a dead technology. In business world stuff tends to run far longer than softawre developers consider. Hell COBOL and PL/1 stuff runs in some places still.

While not as old as your examples, Windows 2003 has just reached EOL, so there are going to be many "crusty" applications that will need to be migrated.

That's exactly why I'm partial to Common Lisp. People can badmouth it as much as they want, but I'm still running Maxima on it, AND the application's language still isn't set in stone by design.

(You've also reminded me again that there's market for document-structure-reconstructing OCR.)

Libreoffice does well on old word and word perfect documents.

It does. Emphasis on "well". Not, however, perfect, especially with more complex documents.

That's mostly an issue where you're working on "live" documents, collaborating with others actively. Once you've reached archival stage it's often safe to convert to something more stable. And I put the fault squarely with Microsoft: utter failure to take archival concerns into consideration.

My own preferred fixes are to convert to Markdown or LaTeX, if the structure supports it, and to other formats from there: PDF, HTMK, ePub.

And no, I haven't used MS Word for a decade and a half.

> it has now become too expensive/time consuming to migrate them off of a dead technology.

Is there a particular reason they genuinely have to be migrated? And the fact that Access/Delphi are a "dead technologies" I'd say is further reinforcement of the point of this article.

> I wonder if my AngularJS/D3.js/jqGrid/etc. single-page app will even load in a browser 20 years from now, let alone perform as originally intended...

Random question for you: In your single-page app, do you support bookmarking "locations" that take multiple clicks to get to, so rather than redo those clicks at a later date, the user can get there via the bookmark? (Assuming your site has locations that require multiple clicks to get to of course.)

Not the parent, but Angular apps often involve rendering different views based on the URL fragment. This is intended to give you "bookmarkability". So for example instead of bookmarking something like this:

http://example.com/users/1234

it would be something like this:

http://example.com/#!/users/1234

Personally, I have found that for SPAs with centralized state, you can serialize the entire application state into the URL fragment. This means that no matter where the user is in the application, they can bookmark that URL and it would return them to exactly the same place that they were (authentication aside). The disadvantage is that the fragment doesn't necessarily "make sense" to the user, and the URL is too long to be conveniently remembered or retyped manually.

IIRC, in recent versions of the angular router, the second, #!-type urls are a fallback for legacy browsers (more precisely, ones that don't support the HTML5 history API). On modern browsers the url will look like your first one.

You are of course right.

Users of software don’t care for the terms developers use to label their creations, “web app” or “web page” — it’s all the same to them. More importantly, they expect an identical behaviour from both. So when a web app can’t recreate its state from URL it’s breaking a fundamental web UI convention.

Another core UI convention that is often disregarded by web app developers is link click behaviour, i.e. you expect anything that performs a function of a link to behave as it normally would when you click on it with mouse’s middle button, or right click → context menu, or left click with modifier keys (cmd/ctrl, shift). Everyone got used to this and when the pattern is broken it is most annoying.

I work with a developer who thinks extremely highly of himself, and he seems to have never heard of this approach for SPA's.

Doesn’t necessarily mean he’s a bad developer; there are many frontend devs who see their job as pure programming. Which it is not. For frontend developer, an important part of the job is to know what a good design is and what concepts underlie it. Yet it’s hard to gain such knowledge without either designing or working closely with designers.

In the App-centric view, you don't bookmark anything. There are no bookmarks in desktop apps, for example. It's just weird that this 'app view' made it onto the web.

We used the Angular document fragment URLs, so it was possible to copy-paste and bookmark things.

This “app view” is natural, because it’s less about bookmarking, and more about sharing — one of the key concepts behind the Web.

URLs are a big deal, and I absolutely loathe systems which actively sabotage likability on the web.

That said, it really was an offline app. We could've done it as a native Qt or .NET app. Even so, the standard AngularJS document fragment paths supported bookmarking and so on.

I just wonder, does it really matter that it does not run in 20 years?

Most of the stuff we do on the web are momental stuff that is only relevant right now. Stuff like Wikipedia will probably not change much since it's only real purpose it to display text. There is no need for an angular app there and in fact it would be a horrible idea to even make it that way.

The stuff that are meant to last long will if we want to.

Reply on news.ycombinator.com