4 ms·
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,
by csirac2 11y ago
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...
- bigger_cheese 11y agoIt'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.
- thejosh 11y agoWhile 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.
- jakub_h 11y agoThat'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.)
- JupiterMoon 11y agoLibreoffice does well on old word and word perfect documents.
- dredmorbius 11y agoIt 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.
- mistermann 11y ago> 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.
- mistermann 11y ago> 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.)
- delluminatus 11y agoNot 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 http://example.com/users/1234 it would be something like this: http://example.com/#!/users/1234 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.
- SEMW 11y agoIIRC, 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.
- temo4ka 11y agoYou 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.
- staticelf 11y agoI 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.