I guess what I'm saying is that if you want to build a site to last 25 years without numerous redesigns, build a static HTML page.

Looks like Web 1.0 got something right after all :)

The author of this website is basically stuck using whatever version of Frontpage supports the markup of his website. And I bet there have been plenty of people who used <some other WYSIWYG webpage editor> who are no longer able to maintain their website because their editor no longer runs on their system.

Apple is pretty annoying in this regard. There’s a lot of software that doesn’t work on versions maybe only 5 years old.

A lot of software doesn’t need to change to be honest. Microsoft word for example. Word processing: you sit down and type stuff, maybe change the font once or twice. I guess the collaborative features are nice being able to edit the same document with others.

It would be fun to use an older machine and see how productive you can be with the old software too !

I suppose you mean this video ?

https://www.dougengelbart.org/content/view/374/

It's a very interesting show, how they solved the displays with commercial cameras filming the lcd displays in the lab and sending to the users screen. How the mouse worked, five button keyboard and so on.

Those applications from 20 years ago running in emulators will work far better in 20 more years than Apps from today that stop working due to remote service dependencies to force vendor lock-in.

It is endlessly amusing to me that the more tightly integrated the cloud services get to conventional computing tasks, the more likely we will end up with Vernor Vinge style programmer archaeologists from A Deepness in the Sky...

So yeah, you're right, emulation saves the day in many cases. And I felt like a programmer-archaeologist using DOS to launch something into space in the 2010s...

I shudder to think of the massive house of cards we will have in 50 years.

Take any given product or system. what percentage of the software involved in implementing the system was written x years in the past. What’s gonna happen to that distribution in 10 or 100 years?

I wonder how inevitable it is that this percentage of ancient software in virtually every system will just keep growing and growing over time — until the systems of the future are tiny layers built on top of 1000 year old, impenetrable old growth forests which as well have been written by aliens for their understandability ...

On the other hand, only OSX 10.7+ are really easy to run in a VM, and .5 and .6 only work for servers, and anything before 10.5 isn't really going to be compatible with virtualization. That's 2007, so OSX lets you virtualize back about 13 years, and Windows you can go back almost 30 years. People even have Win 3.1 running in VMware.

This is probably due to the fact that there isn't powerpc virtualization software, but if you need to run osx software from before 2007, you're basically out of luck.

You can also virtualize windows from just about any OS you can imagine, Mac, Linux, Windows etc, while OSX virtualization has a hard requirement for running on Mac hardware.

I was able to import almost everything from my old PPC computers. It's not completely virtualized because is using Rosetta and can not use Classic OS apps. But it is still extremely useful, and way faster than my PPC computers ever were.

[1]: https://github.com/ranma42/TigerOnVBox

If you aren't a stickler for Apple's terms of service (if you're doing this for business purposes, I suggest you should be), you can use a tool called macOS unlocker to patch VMWare Workstation to run macOS VMs. Runs great, though all VMWare products can only render display output for macOS in software mode.

I've ran MacOS in VirtualBox iirc, without shady patches―though it probably was in Linux.

It may be more common in Windows, but I would challenge that since Windows is basically free and runs on anything from a raspberry pi up, the vast majority of "hacky" stuff happens in Windows and Linux. Mac users buy very, very expensive hardware to do very specific tasks, and "hack around" is often not a good enough justification for the most expensive personal computers money buys.

I would also suggest that it in the Linux world where running random binaries as root is most common. Found some random repo that claims it's a fork of a good one with a bug fix? Build it and run it!

https://www.thefreecountry.com/emulators/macintosh.shtml#pow...

For the most part yes. If you want to run Mac software you need to own Mac.

As far as going back 30 years. Now you’re in the Classic Mac era. There are plenty of cross platform emulators that run Mac software that old.

If you want to go back 40 years. Apple // emulators are a dime a dozen.

What, Basilisk II and Sheep Shaver? PCE and Mini vMac if you want a Mac Plus. For a large array of apps only one of these options will actually work.

I’d been wanting a Mac for several years, but had little understanding of how it worked. PearPC let me try it out and a get a glimpse of Mac OS X.

Microsoft Windows 10 is able to run software that predates all of Apple's supported platforms.

Someone else was complaining that they didn’t keep FireWire. Should modern Macs come with ADB ports?

A 20-year old machine that's critical to a factory can run off a serial cable plugged in to an expansion card running software written in the 90's that will still run on Windows 10. Nobody in their right mind would decide to write that same software on a Mac.

If you compare where Apple is and where Microsoft is also, it doesn’t seem like chasing enterprise PC sales was as good of a long term bet as going after the consumer market....

I don't think it's unreasonable that Apple hasn't done so, but neither do I think doing so would be unreasonable. Archive.org can emulate Apple II's in your browser, I'm sure Apple could add an equivalent feature to MacOS if that were something they cared to do. They obviously don't, and that's their prerogative.

https://www.apple.com/shop/product/MD464LL/A/apple-thunderbo...

The point upthread was that genuinely useful stuff gets retired just a few years after release in the Apple world, and I think that's broadly true. It's true with hardware too -- professional audio people are stuck with truckloads of firewire hardware that they can't use with their new laptops, for example.

No the closest ancestor to MacOS X is System 7. There were Carbon APIs until last year. A poster up thread said they could use an emulator. There are 68K Mac emulators available too.

AppleScript for instance is a System 7 technology - not a NextStep technology.

How do you figure?

System 7 was part of the Classic Mac OS line, the last of that line was System 9 (Mac OS 9). This was a proprietary kernel developed by Apple.

Mac OS X is a Unix based OS derived from technologies they acquired from NeXT.

To say MacOS X is an ancestor of System 7 seems completely nonsensical.

The entire Carbon API was a port of classic MacOS APIs to make porting from classic MacOS to OS X easier.

MacOS X was a combination of both. That was the whole brouhaha of why Apple ported Carbon APIS to OS X because major developers like Adobe and Microsoft insisted on it.

That’s not to mention that the first 5 versions of MacOS had an entire OS 9 emulator built in.

To take the analogy to the extreme. MacOS had two parents - Classic MacOS and NextStep.

I think you're just supporting the original assertion that Apple does not support things for very long. Does Software written for OS X v10.1 run on Catalina today without using 3rd party tools or emulators? Software written for Windows 95 still runs on Windows 10.

Carbon was a port of enough of the Classic API to port major important programs.

AppleScript is still built into the current version of OS X. It was introduced in 1993-94

And seeing that 10.1 was PPC only, do you expect them to keep a PPC emulator around?

Can you run PPC based Windows NT software today on an x86 PC?

Sure, Carbon and Rosetta certainly were no mean feat, and the drastic PPC/x86 break is something Microsoft never really had to deal with (heh, the biggest problem trying to run a PPC/MIPS/Alpha based NT application today is actually finding one :) ).

But Apple never went to the same lengths as Microsoft regarding backwards compatibility, and while Carbon and Rosetta immensely eased the transition, the continuity definitely wasn't comparable and it was never transparent to the developers (and in Apple's defense, this was never their intention and they always were quite open about it.)

For one, Rosetta (and thus PPC compatibility) was dropped with Lion in 2011, so no amount of Carbon would help 10.1 applications after that.

And even with Rosetta, each release, especially after Tiger, came with quite a list of API changes and deprecations (with the whole of Carbon declared obsolete in 2012) - and and increasingly longer list of high-profile software that would not run anymore and require an update or upgrade. And while Microsoft did a lot even to prevent and/or work around issues with notorious software (hello Adobe! :) ), Apple was far less willing to do so.

I mean, just as an example - I can run Photoshop 6.0 (from 2000) on Windows 10 (certainly no thanks to Adobe), but no chance for PS 7.0 even on Leopard...

Porting from PPC to x86 was relatively easy. But you’re also forgetting about the first transition - from 68K to PPC.

Can you run the PPC version of any Windows NT apps?

Apple announced it's plans to move to OS X in 1997 and that they'd ship an emulator, Blue Box, to run classic apps. That was met with a resounding "no" from the community.

Carbon was never suppose to exist, the Classic APIs were not memory safe, don't support thread, and had a lot of other issues. Apple wanted a clean break in the form of Cocoa but the community said no. So Apple came up with Carbon, which was sort of a port of Classic APIs to OS X, but because the two operating systems were so different it wasn't anywhere close to a 1:1 copy and required developers to port to it.

Since it's inception, Apple wanted Carbon dead, it required them to rewrite core parts of OpenStep in C and they had to maintain them alongside their Obj-C equivalents. It took them 12 years to get to the point where they felt comfortable killing it off and almost 20 years before they actually could.

> Can you run the PPC version of any Windows NT apps?

Developing for PPC was much like targeting x86 and PPC on a OS X. It was mostly a recompile unless the App used assembly. You can't run the PPC version of an NT app on modern hardware just as you can't run the PPC version of an OSX app on MacOS.

The difference thought is that PPC on NT never took off so there's something like 4 or 5 Apps for NT versus the thousands or hundreds of thousands for OSX.

I think you missed the entire point of my posting, i.e. that even outside the architecture changes long term compatibility was never even near the same level (and different arch often not even the culprit). Carbon being available doesn't help you a thing when old software still doesn't work.

Yes I realize that PPC Macs came out in 1994. But they required a 68K emulator because even parts of MacOS were 68K.

But I ain't. I'm arguing that for vast stretches of Mac OS/OS X/macOS history, even 5 year old software has been a gamble.

There were three major breaking changes for MacOS.

- If you bought the x86 version of software in 2006. It would potentially work until 2019 when Apple dropped 32 support.

- If you bought the first first version of OS X PPC software in 2001, it could potentially run until July 2011 with the release of 10.7.

- If you bought a classic MacOS app, it could run from pessimistically from 1992 with the release of System 7 to 2006 with the introduction of the first x86 Macs.

"Carbon was an important part of Apple's strategy for bringing Mac OS X to market, offering a path for quick porting of existing software applications, as well as a means of shipping applications that would run on either Mac OS X or the classic Mac OS. As the market has increasingly moved to the Cocoa-based frameworks, especially after the release of iOS, the need for a porting library was diluted. Apple did not create a 64-bit version of Carbon while updating their other frameworks in the 2007 time-frame, and eventually deprecated the entire API in OS X 10.8 Mountain Lion, which was released on July 24, 2012. Carbon was officially discontinued and removed entirely with the release of macOS 10.15 Catalina."

I think you are confusing "supported" with EoL. Adobe was pissed because there was originally talk of doing a carbon64bit and they never supported it so they had to move their entire app over.

The main point is, that Windows would never stop that api from "existing" In some manner. Unlike Apple.

This is just a difference in how both companies view themselves. While Apple claims "it just works". That isn't quite true in some of the cases we have seen. Microsoft has actually done a far better job of this.

I know someone that worked on the visual studio team. They literally had 100-200 servers that would run overnight with each build guaranteeing that the software would install and run on every single permutation of windows on an array of hardware.

The Carbon API was 32 bit only and was supported until the latest release of MacOS.

Do you realize how many deprecated end of life frameworks that Microsoft has been lugging around for decades?

So should Apple have kept support for 68K software in 2019?

Also, do you realize that for all intents and purposes the entire .Net Framework is deprecated and EOL except for minor compatibility updates?

There are plenty of “pissed” .Net Framework developers who feel abandoned by MS.

From a web perspective (and my experience), .NET Framework 2/4 -> Core is actually not a big changeover outside of the views (probably better if you switched to MVC).

The Windows Phone apps I built are dead now, but that isn't a matter of APIs no longer being supported, but an entire platform going under.

As a macOS user, I had one operating system update kill external GPU w/ Nvidia cards (that sucked) and another update kill 32 bit apps (that one isn't a big one for me personally). All on the same computer.

Microsoft also completely abandoned Windows CE/Compact Framework while there were plenty of companies that had deployed thousands of $1200-$2000 ruggedized devices for field services work.

There's been a lot of confusion, due in no small part to Microsoft's branding and communication, but what you said is not at all accurate if not intentionally misleading.

What's been know as .NET for the last 20 years is now called ".NET Framework", this is not unlike how OS X is now called MacOS retroactively. ".NET Core" is an entirely new framework that just happened to be compatible with ".NET Framework" but as time goes on the two have diverged.

> Not to mention all of the legacy third party .Net Framework only third party packages that don’t work.

".NET Framework" and ".NET Core" are similar to Cocoa and Cocoa Touch in the sense that you can write code that will compile under both AND you can write code for either that will be incompatible with the other. In fact I maintain a half dozen packages that are compatible with both.

> Microsoft also completely abandoned Windows CE/Compact Framework while there were plenty of companies that had deployed thousands of $1200-$2000 ruggedized devices for field services work.

Microsoft didn't "abandoned" Windows CE, it stopped development for it 6 years ago as it was largely dead and Microsoft offers many pathways off of Windows CE. The CF actually runs on platforms other than CE intentionally such that any apps written for the CF will just work elsewhere. AND they still support CE and CF to this day, they just don't maintain or develop new versions of them.

The two weren’t initially slated to diverge at all. .Net Framework and .Net Core were suppose to be separate implementations of “.Net Standard”. In fact, you could originally create ASP.Net Core and EF Core apps that ran on top of .Net Framework.

NET Framework" and ".NET Core" are similar to Cocoa and Cocoa Touch in the sense that you can write code that will compile under both AND you can write code for either that will be incompatible with the other. In fact I maintain a half dozen packages that are compatible with both.

Which will not be the case for long since MS has stated that no new features will come to .Net Framework.

Microsoft didn't "abandoned" Windows CE, it stopped development for it 6 years ago as it was largely dead and Microsoft offers many pathways off of Windows CE. The CF actually runs on platforms other than CE intentionally such that any apps written for the CF will just work elsewhere. AND they still support CE and CF to this day, they just don't maintain or develop new versions of them.

Which is also not true. The last version of Visual Studio that supported Compact Framework was VS 2007. It was far from dead in the Enterprise by 2010 or even 2012. Companies were still relying on CF to run on their $1200-$2000 ruggedized field service devices. They had deployed literally thousands of devices in the field. I know, I was developing on VS 2007 until 2011 just to support them.

I mean devices like these that cost $1300 each. I deployed software for a few companies that’s had thousands of Intermech and ruggedized Motorola devices.

https://3er1viui9wo30pkxh1v2nh4w-wpengine.netdna-ssl.com/wp-...

Uh... no. Hard fucking no. .NET Standard is the commonalities between Core and Framework. Core and Framework were NEVER the same or intended to be the same.

Framework is all of the legacy Windows specific Libraries for things like the File System, Active Directory, etc.

Core is intended to be platform agnostic and cross platform.

Read this, specifically Figure 5:

https://docs.microsoft.com/en-us/archive/msdn-magazine/2017/...

> The last version of Visual Studio that supported Compact Framework was VS 2007.

Windows Embedded Compact 2013 shipped with CF 3.9 in 2012.

Hell, you can run VB6 apps on Win10 - it even ships the runtime! - and the remaining hold-outs in that developer community have been complaining about abandonment for two whole decades now.

The .NET Framework 1.1 is not supported on the Windows 8, Windows 8.1, Windows Server 2012, Windows Server 2012 R2, or the Windows 10 operating systems. In some cases, the .NET Framework 1.1 is specifically identified as required for an app to run. In those cases, you should contact your independent software vendor (ISV) to have the app upgraded to run on the .NET Framework 3.5 SP1 or later version. For additional information, see Migrating from the .NET Framework 1.1.

By “specifically identified” it means that some applications actually hard coded a check of 1.1.

The callout exists because Microsoft takes a different approach to support from Apple. Microsoft provides support material for all of it's legacy and deprecated software, as well as the ability to download and install them. So it's important to identify and track incompatibilities between them.

When Apple moves the past is whitewashed over and when support stops they forget it ever happened.

What's mildly annoying is that much of the early 32bit Windows software came packaged in 16 bit installers. Office 97 would be such a breeze on modern hardware.

But at least getting it done largely depends only on them, and it's not too hard. I have friends who swear by ProTracker and still use it, even though it's thirty years old and the platform it's running on has been dead for more than twenty. They don't have an Amiga but it's trivial to get it running in an emulator today.

You can run Windows 98 in a browser, and your web editor in it. It's certainly less complicated than hosting a WebObjects application today.

The whole thing is terrifying and horrific to me, but they keep paying her to do the work so she's fine with it.

With all the churn in certain areas of tech, it's easy to forget how much stays the same.

I was using Macromedia Fireworks MX from the early 2000's right through about 2013 to do graphics for sites I was building people on the side.

I used it while it got several version updates, Adobe took it over and updated it for five or six years, and then discontinued it.

Meanwhile I was still using the old version to make beer money.

I only quit using it because I finally admitted I kind of suck at graphic design. Besides, there doesn't seem to be much need for graphic design in much of the modern mobile-first, material design world anyway.

I bailed on the whole thing and have been sticking to back end at the day job these days. Things move at a slightly less hectic pace back here for me most of the time.

That said, neither app has the WYSIWYG editing that DreamWeaver had. But I've always preferred to hand ode my HTML anyway.

Yeah you could always edit the individual files that it outputted, but in some cases people were using this system to manage sites with hundreds or thousands of pages. As recently as a couple years ago it was how the natural history museum in DC managed their site content.

I know a website that is still maintained regulary and built with dreamweaver 2003

Years ago I found a "Portable Frontpage" which of course I downloaded and still have somewhere zipped. I know that MS wouldn't like this much, but life is life and Portable Frontpage exists. So as long as there are Windows, Frontpage will work!

and

> I guess what I'm saying is that if you want to build a site to last 25 years without numerous redesigns, build a static HTML page.

While simplicity is a great way to future proof things, I'm not convinced that this argument in general would work nearly as well without the benefit of hindsight. One could be forgiven for confusing it with "guess the future correctly". Plenty of relatively safe bets from 10, 20, 30 years ago haven't panned out that well. It's an interesting line of thinking though: exactly what properties of HTML make it so long lived?

edit: A few more popped into my head. CSV. SQL schema + Data dumps (text format). The common theme to everything here is plain text. SQLite, although binary, is probably close to eternal. Git is eternal enough (recent HN post showed even POSIX shell is good enough to write a basic git client). JSON is easy to write a parser for as well. YAML.

It's not so much that you needed to guess that HTML was going to be as long-lived as it is, it's that HTML is the final product that actually loads on the users computer, and those tend to stick around for a long time (or at least be emulated). The code that lives on a backend server somewhere, not so much.

For what it's worth, I don't think this example is necessarily bulletproof: it requires a working copy of Frontpage. If Microsoft behaved more like Apple it might have been deprecated away long ago!

I'm currently tasked with writing a UI for a machine that has a 25 year expected lifespan before wear means it is replaced. This is a real concern - think about where computers were 25 years ago and try to find something you are sure will work and look nice.

Matters are even worse. Last year, the W3C became the "yes-man" of Google. They decided to stop developing the HTML standards and just start rubber stamping whatever WHATWG produces. WHATWG is run by Apple, Google, Microsoft, and Mozilla. And who has the most power in that relationship? Yep, Google.

While Safari, when mobile is included, has ~17% of the market, that's not enough when you combine Google's browser share along with their search engine share.

The only thing I can come up with is http (no s!) and firewall rules that limit connections to 192.168.1.xxx - or otherwise not allowing connections from outside of the local subnet. I don't like it, but I don't have a better plan.

I don't think Markdown is going anyway, incidentally, or that it would be hard to process on my own if I needed to. But the HTML I use is simple enough and Markdown only decreases the probability the site will last a long time.

Since there's no single Markdown spec, determining just how a page will render, or what will break, is a bit of a crapshoot. And since Markdown treats nonparsable markup as ... plain text, you don't even get errors or other indicators of failure. You've got to view and validate the output manually or by some other means.

With formal tag-based markup languages (HTML, SGML, LaTeX, DocBook, etc.) you've at least got 1) an actual markup spec and 2) something that will or won't validate (though whether or not the processor actually gives a damn about that is another question, hello, HTML, I'm looking at your "The Web is an error condition": https://deirdre.net/programming-sucks-why-i-quit/)

I can't find the post at the moment, but someone recently wrote a cogent rant on the fact that a change in their hosting provider (GitHub via a static site generator IIRC) had swapped out markdown processors, with changed behaviours, rendering (literally) all their previously-authored content broken.

Which is indead a pain.

I personally like Markdown, and find it hugely convenient. For major projects though, I suspect what I'll end up doing is starting in Markdown, and eventually switching to a more stable markup format, which probably means LaTeX (HTML has ... proved less robustly stable over the 25+ years I've worked with it).

Though for simple-to-modestly-complex documents, Markdown is generally satisfactory, stable, and close enough to unadorned ASCII that fixing what breaks is not a horribly complicated task.

Up to modest levels of scale, at least.

> HTML has ... proved less robustly stable over the 25+ years I've worked with it

The first website I made in 2002 still views fine in a modern browser. I didn't do anything fancy, though. I would be interested in what has been unstable as it might give me ideas on what to avoid in HTML.

I don't find HTML to be that much harder than plain text or Markdown so I think I'll keep using it for smaller projects. LaTeX is worth considering as well, particularly given that I will have math on some of my webpages. One issue is that the stability of LaTeX depends strongly on which packages you use. I need to take a closer look at the health of every package I use. I think avoiding external dependencies is easier with HTML.

For certain more complex formatting, Markdown has limitations and features are more likely to change. But I've used Markdown to format novel-length works (from ASCII sources, for my own use) with very modest formatting needs (chapters, some italic or bold text, possibly blockquotes or lists), and it excels at that.

For HTML, it's a combination of factors:

- Previous features which have been dropped, most to thunderous applause. (<blink>, <marquee>, etc.)

- Previous conventions which have largely been supersceded: table layouts most especially. CSS really has been ... in some respects ... a blessing.

- Nagging omissions. The fact that there's no HTML-native footnoting / endnoting convention ... bothers me. You can tool that into a page. But you can't simply do something like:

    <p>Lorem ipsum dolor sit amet.
        <note>Consectetur adipiscing elit</note> 
        Nulla malesuada, mauris ac tincidunt faucibus</p>

In Markdown you accomplish this by:

    Lorem ipsum dolor sit amet.[^consectetur] Nulla malesuada, mauris ac tincidunt faucibus

    [^consectetur]: Consectetur adipiscing elit.

- Similarly, no native equation support.

Maybe I'm just overly fond of footnotes and equations....

But HTML and WWW originated, literally, from the world's leading particle physics laboratory. You'd think it might include such capabilities.

- Scripting and preprocessors. I remember server-side includes, there's PHP, and JS. Some browsers supported other languages -- I believe Tcl and Lua are among those that have been used. Interactivity and dependency on other moving parts reduces reliability.

The expression "complexity is the enemy of reliabilty" dates to an Economist article in 1958. It remains very, very true.

HTML is for me more fiddly than Markdown (though I've coded massive amounts of both by hand), so on balance, I prefer writing Markdown (it's become very nearly completely natural to me). OTOH, LaTeX isn't much more complex than HTML, and in many cases (simple paragraphs) far simpler, so if I had to make a switch, that's the direction I'd more likely go.

> The fact that there's no HTML-native footnoting / endnoting convention ... bothers me.

I've seen people use the HTML5 <aside> element for sidenotes, styled with CSS. Some even make them responsive, folding neatly into the text as the viewport shrinks. I'm not sure if this is the intended use for <aside> but the result is reasonable and I intend to do the same. If you're set on footnotes, though, yes, I don't know a native implementation.

Equation support with MathML is okay in principle but not practice. I'd like to have equations without external dependencies (MathJax's JS alone is like 750 kB!), but that's not possible until Chrome decides to catch up with Firefox and Sarafi on MathML. I've been thinking about just using MathML as-is (no external math renderer), and if Chrome users complain, I'll tell them to get a better browser. ;-) Maybe that'll help some Chrome users understand why they should test their websites in other browsers.

[1] http://www.unicode.org/notes/tn28/UTN28-PlainTextMath-v3.pdf

> I haven't paid much attention to multi-column layouts in CSS over the years but my impression is that it's gone from tables to CSS floats to whatever CSS does now that I'm not familiar with.

CSS Grid [2] is the happiest path today. It's a really happy path (I want these columns, this wide, done). CSS Flexbox [3] is a bit older and nearly as happy a path. Some really powerful things can be used with the combination of both, especially in responsive design (a dense two dimensional grid on large widescreen displays collapsing to a simple flexbox "one dimensional" flow, for example).

Flexbox may be seen as primitive in a few years, but Grid finally seems exactly where things should have always been (and what people were trying to accomplish way back when with tables or worse framesets). Even then, Flexbox may be mostly seen as primitive from the sense of "simple lego/duplo tool" compared to Grid's more precise/powerful/capable tools.

[2] https://caniuse.com/#feat=css-grid

[3] https://caniuse.com/#feat=flexbox

I'll also look more closely at CSS Grid.

CSS columns and Grid are not entirley substitutable, though they share some properties.

I see Columns as a way of flowing text within some bounding box, whilst Grid is preferred for arranging textual components on a page, more akin to paste-up in Aldus Pagemaker (am I dating myself) though on the rubber sheet of the HTML viewport rather than on fixed paper sizes.

[1] https://hacks.mozilla.org/2019/11/multiple-column-layout-and...

https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Columns...

My preference is to use them with @media queries to create more or fewer columns within auxiliary elements (headers, footers, asides), usually to pretty good effect.

Multi-column body text is largely an abombination.

For images, I'm still largely sticking to floats.

I've done some sidenote styling that I ... think I like. I don't remember how responsive this CodePen is or isn't though I've created some pretty responsive layouts based on it:

https://codepen.io/dredmorbius/full/OVmKZX

I consider equation support a lost cause.

If a Markdown parser breaks down, it's quite correct for it to just spit out the raw source document—because the raw document is already a readable document with clear (cultural/conventional) semantics. All a Markdown parser does is make a Markdown-styled text prettier; it was already a readable final document.

Markdown's job is to be a human-readable, lightweight, unobtrusive way of communicating to software how to structure and format a document.

It's one thing for a freshly-entered document to fail -- errors in markup occur and need to be corrected. It's another to change the behaviour and output of an unchanged text, which is what Markdown implementations have done.

(I've run into this myself on Ello where, For Mysterious and Diverse Reasons, posts and comments which I'd previously entered change their rendering even when I've not touched the content myself. This is compounded by an idiotic editor which literally won't not muck with plain ASCII text entered and insists on inserting or creating hidden characters or control codes. Among the reasons for my eventual disenchantement of what would otherwise be an excellent long-form text-publishing platform.)

No, that’s a misunderstanding. Markdown is, as I said, a formalization of existing practice. Nobody’s supposed to be “writing Markdown” (except computers that generate it.) You’re supposed to be writing plaintext styled text the same way you always have been in plaintext text inputs. Markdown is supposed to come along and pick up the pieces and turn them into rich text to the best of its ability. Where it fails, it leaves behind the original styled text, which retains the same communication semantics to other humans that the post-transformation rich text would.

The ideal Markdown parser isn’t a grammar/ruleset, but an ML system that understands, learns, and evolves over time with how humans use ASCII art to style plaintext. It’s an autoencoder between streams of ASCII-art text and the production of an AST. (In training such a system, it’d probably also learn—whether you’d like it to or not—to encode ASCII-art smilies as emoji; to encode entirely-parenthetical paragraphs as floating sidebars; to generate tables of contents; etc. These are all “in scope” for the concept of Markdown.)

In short: you aren’t supposed to learn Markdown; Markdown is supposed to learn you (the general “you”, i.e. humans who write in plaintext) and your way of expressing styles.

If there’s any required syntax in Markdown that a human unversed in Markdown wouldn’t understand at first glance as part of a plaintext e-mail, then Markdown as a project has failed. (This is partly why Markdown doesn’t cover every potentially kind of formatting: some rich-text formatting tags just don’t have any ASCII-art-styled plaintext conventions that people will recognize, so Markdown cannot include them. That’s where Markdown expects you to just write HTML instead, because at that point you’ve left the domain of the “things non-computer people reading will understand”, so you may as well use a powerful explicit formal language, rather than a conventional one.)

At least not today ;-)

Human expression is ultimately ambiguous. In creating some typographic output, you've got to ultimately resolve or remove that ambiguity. Preferably in some consistent fashion.

There's an inherent tension there. And either you live with the ambiguity or you resolve it. I lean on the "deambiguate" side. Maybe that means using Markdown as a starting point and translating it ultimately to some less-ambiguous (but also less convenient) format, as I've noted.

But that means that the "authoritative source" (Markdown manuscript) is not authoritative, at least as regards formatting guidelines. Whether or not this is actually a more accurate reflection of the status quo ante in previous, print-based, typographic practice, in which an author submits a text but a typesetter translates that into a typographic projection, making interpretations where necessary to resolve ambiguities or approximate initial intent, I don't know.

Interesting from a philosophical intent/instantiation perspective though.

The vast bulk of software goes unsupported in less than 25 years. If you want to depend on something that long, you can guess which package will survive that long, or you can store your data in formats that the widest array of tooling supports.

If you drop into a coma after uploading your static HTML and wake up in 25 years, you might have to use whatever fills the text-manipulation-scripting niche then to beat it into the right shape to import into whatever kids these days are using.

If you used Wordpress, well, maybe it takes over the world, maybe it ends up a Wikipedia entry. (Putting aside, of course, that your site began hosting cryptominers a week after you slipped into that coma because you missed an update.)

I've thought about this on and off for a few years. Here's what I've come up with:

1. Popularity. You can't really display anything in a web browser without it, blank pages with one AJAX script notwithstanding.

2. Ease of use. Open a text editor, type some markup, save the file with .html, and open in a browser. When you're done, transfer to a server to show the world. That's a pretty straightforward process.

3. Well-defined, open standard. Every important piece of the web is defined, from the markup to the protocol to transfer it. I think that reasonably bug-free implementations of those standards help.

It's not that there's a well-defined open standard.

It's that browsers will eat any old crap that's thrown at them and turn it into something plausible, if not precisely what the author intended or reader really wants.

Yes, there's a standard, and yes it's open. It's observed far more in the breach, as a few minutes with a validator on well-known sites will demonstrate.

Your comment alone (prior to my response to it) returns:

    Tidy found 21 warnings and 0 errors!

HTML was based on SGML and it has all the nice SGML features. Something like <title/Hello World/ was valid HTML afair.

But then the browser never implemented it properly, so html5 just describes the behaviour of the browsers.

Reminds me of the fairly prescient "In Praise of Evolvable Systems" essay from 1996: https://web.archive.org/web/20190409041249/http://www.shirky...

How many blogs are powered by wordpress? How many of them can be replaced with a static gen?

HTML has a lot of garbage, but at least it's very hard to break it.

and really it's that everyone uses browsers that still display text and such on the screen even if it's broken in several places.

This could change if google decided to stop showing pages with broken html - like them killing flash big cuts at a time.

I have turned several worpress based sites into static html with one of the static html making plugins - and that turned those tools into the right ones for those jobs. I think most WP sites can be converted and be just fine, most people don't add new posts to them regularly from what I've seen.

I think we're thinking about this backwards. It's not anything inherent to HTML that make it long lived, it's that the code to parse static HTML is simple, it's more or less standardized and has stuck around for a long time.

In the early 2000s XML was the cool shiny thing. They're still using it, in fact I found out recently that someone wrote a Markdown to 'doctype grahame' converter to 'modernise' the site.

I guess what I actually built back then was an early static site generator, but it's still kind of cool they're using it 19 years later, hacky as it was / is :)

I regret nothing. Editing simple xml using Emacs is a breeze.

[1] https://www.navitaire.com/new-skies-reservation-system

My personal website uses Jekyll, and while there's always the possibility it would become abandoned and stop working (I've definitely found someupgrades to be a pain, and ruby tooling in general doesn't help either), I'll always have the simple, readable markdown files the site is based on. While this wouldn't be an option for a non-technical website author, if I really had to, I'm sure I could write a simple markdown->html renderer over a weekend (or a converter to transform it into the future format-du-jour).

Of course you could run it yourself, but maintaining a server for a basic blog or personal site arguably exits the realm of "simple."

The secret is creating a standard early on that thousands of different pieces of software depend on, so that changing it would expensive and require a phenomenal amount of decentralized coordination.

Don't worry about making it good -- just make it good enough that people won't want to tear their hair out and unanimously agree to never touch it again. Make the short term cost of applying hacks on top of it low, and the cost of throwing everything out high.

[1] https://trac.edgewall.org/

Maybe it will be upgraded now that python 2 is officially dead, but given it wasn't so far and there was no effort in that direction, I wouldn't bet on it.

https://trac.edgewall.org/wiki/TracChangeLog

End of life is correct. It is end of life since it doesn't run on current platforms.

I am not sure if the latest distributions (Ubuntu, Debian, RedHat) have all removed python 2 packages. If not, it will be gone with the next major release. You're going to be in trouble to run software with no available interpreter, plus all the libraries in use are effectively abandoned.

Red Hat has not. Ubuntu has not in its most recent stable release. Debian "unstable" is still using Python 2, so I don't think your statement holds up.

https://distrowatch.com/table.php?distribution=redhat

https://distrowatch.com/table.php?distribution=ubuntu

https://distrowatch.com/table.php?distribution=debian

Also, Trac developers ave been making progress on Python3 as recently as 8 days ago:

https://trac.edgewall.org/ticket/12130

    Good Practice: Use the least powerful language suitable for expressing information, constraints or programs on the World Wide Web.[0]

I'm aware. It got hacked in like 2007 but (I think?) never since. I run some other stuff on that box and sometimes look at the resource usage etc.

Also suggesting that "most of the web" runs on WordPress is a bit absurd. WordPress accounts for a huge portion of spam-y SEO blogs and other outright noise on the web. It's popular no doubt but definitely not most of the web.

It's popularity and porous security is a big problem as it's such a huge malware delivery vector. Everything from worm payloads to JavaScript crypto miners is served up from millions of exploited WordPress installs.

I was able to convince the bosses to let me take on the fixing-the-site project solo, even though my job has little do with IT. I replaced it all with a static site generator I wrote in Go. No logins, no PHP, no database, nothing to exploit in the first place. Anyone in the office can update it by copying images into arbitrary subfolders in the generator's images folders, and double-clicking the update executable. It builds and uploads a fresh site in a couple of minutes with nice gallery carousels. And as a bonus it loads basically instantly on even the bargain-basement shared hosting we're on.

I do wish that IE compatibility wasn't one of the bosses' firm requirements, due to a lot of our clients not being tech people and still using IE on decade-old computers. Life would be so much simpler if I could just use CSS grids for layout. I f'ing love grids.

It's okay if you hate it, but these are the stats

None of that is material to the original point that thousands upon thousands of unpatched WordPress sites might work but also deliver tons of malware. WordPress' popularity is problematic because it has had a d will keep having serious security problems. WordPress exploits are entirely automated and performed constantly by zombie networks.

Sounds similar to the Lindy Effect.[0]

[0] - https://en.wikipedia.org/wiki/Lindy_effect

It's had around 8 million page views in that time.

No way in hell today’s HTML will survive 25 years now that google owns it, browsers will literally crash due to lack of user tracking. Best just host a static txt file.

The ancient Egyptians knew something about this.

Even if the OS and software effectively die, you still would be able to run the latest version in a VM or in emulation.

with some tweaking, it can be viewed in just about any browser, down to ie3, lynx, mosaic, netscape, and opera3.

If you keep active on your Wordpress install, the regular updates will be no issue for you and will (almost) never break your website. Not sure why you would expect a regular Wordpress user to run the initial install without recommended/mandatory upgrades over a long period of time.

It's gone through many renames and redesigns, but, in true Japanese style, it's still the same website. I do have an old snapshot, though: https://anonymoussoftware.stavros.io/

thats quite a conversation starter...

Hint: "Liar" is the lie.

I am a below average driver, alas. I am Greek, though, and some would say that's more exciting!

From what I've heard, you might as well smash your side mirrors off at the dealer when you buy a car, aha...so, yeah, checks out.

I hate driving here.

Amusing to myself and contributing to overall Ship of Theseus analogy, the current design is a responsive, flexbox-based recreation of sorts of the original goals for that 1999 site. I'd like to think the 1999 version of myself would very much appreciate it (especially after all the work in making corner GIFs versus the magic of CSS border-radius, and fighting TABLEs for layous).

I have five different models of ESP8266 and ESP32s scattered across my desk along with Dupont wires, assorted sensors and a soldering iron, breadboards etc. Its a great way of taking your mind off the daily grind - my job title is MD.

Geocrasher said:

> I guess what I'm saying is that if you want to build a site to last 25 years without numerous redesigns, build a static HTML page.

Yes. I don't get paid to maintain my personal site, so simplicity and longevity are most important. If I have to rewrite things because of incompatible changes in the infrastructure components (e.g., Python2 to Python3), or because proprietary company C has decided to stop supporting product P that I depend on, then I have to spend time that doesn't actually provide any new value. Keeping things simple, and minimizing dependencies, can be useful. Like everything else, there's a trade-off.

1. https://jeffhuang.com/designed_to_last/

I'm taking a look at https://dwheeler.com/essays/easy-cross-platform-gui.html, which has references to XULRunner etc. which since 2009 have fallen out of favor.

Would you continue to recommend those wanting to invest in (for the 80% of use cases) wxWidgets for FLOSS cross-platform GUI apps? BoaConstructor et. al look interesting.

Thanks for taking the time to look at this comment. If it helps give you some context, I'll throw in that I currently am most familiar with WinForms .NET apps or very small Win32 native applications, and have avoided JS successfully so far.

So I don't see how WxWidgets is an outlier here.

rot13

It had millions of pageviews, made over 6 figures a month in AdSense and been updated so often and for so long that the owner didn’t actually know how many pages there were. Had to hire someone just to index it.

Not bad for plain old html and css.

https://godaddy.com/domain-value-appraisal/appraisal/?checkA...

https://docs.oracle.com/cd/E19455-01/806-0169/overview-9/ind...

Thin space (U+2009) is also how you are supposed to do it when using the SI unit system, according to the SI spec. For the decimal separator, the SI standard is to use which of '.' or ',' is customary.

Loads super fast.

> My charge for typical business or civil work is $450.00 per hour.

To one that said:

> I am a relative newcomer to the world of turtles.

...in two clicks. I love this site.

Also learned a recipe for a quick and easy blackberry cobbler[0].

[0]: http://www.burger.com/bcobbler.htm

Probably not ;)

> Initial release 1993; 27 years ago

https://en.wikipedia.org/wiki/HTML

  $ nc www0.cs.ucl.ac.uk 80
  HEAD /staff/m.handley/ HTTP/1.0                    

  HTTP/1.0 200 Document follows
  MIME-Version: 1.0
  Server: CERN/3.0
  Date: Fri, 14 Feb 2020 17:02:59 GMT
  Content-Type: text/html
  Content-Length: 9185
  Last-Modified: Sun, 16 Jun 2019 15:27:37 GMT

- drop 99% of the JS (PWA, lazy-loading, infinite scroll, jquery, you don't need any of them for a webpage), convert the remaining for 1% to vanilla js and use it as progressive enhancement.

- use EM or % as layout width/height

- inline css, js, and svg

EDIT

- no webfonts!

The only thing that'll remain as an issue are tables wider, than viewport, on mobile.

My site: https://developers.google.com/speed/pagespeed/insights/?url=...

But yeah, lazy-loading, infinite scroll, etc., are all designed to cover up design flaws that impact performance. I think lazy-loading can be potentially done right, but almost none of us do anything right.

> use EM or % as layout width/height

Why? EM/REM is good for handling font sizes, but for anything else it may not make sense and a custom font setting in the browser can break layouts if the size of boxes are based on font sizes. PX is perfectly adequate for layout, and is actually a relative unit(PX !== hardware pixel). Same for borders, padding, margin, etc. Even REM is better than EM for most cases. People who adjust the font size in their browser don't necessarily want their layout to change and potentially degrade as a result.

> inline css, js, and svg

Can be a good idea, especially if you can somehow identify the CSS used on page load and discard anything nonessential. Though maybe HTTP/2 makes inlining obsolete. IDK

> no webfonts!

Thank you! Web fonts are perfectly sufficient in 99% of cases.

I had a lot of bad experience with px, but it is true that for borders it's the only reasonable choice.

REM is not that well supported, especially in awkward browsers (Dillo, for example).

Imo EM is nicer for padding/margin; it keeps the text/layout ratio even if the font is resized, unlike px.

But point taken, it cannot be used as the only unit.

1) Forces a particular size/resolution, locking out zoom capabilities

2) Has a floating header with a constant size relative to your device screen, blotting out the same real estate no matter how much you zoom. And, of course, using the same header pixel height for portrait vs landscape, making the latter practically unusable.

Yes, this site is better than 99% of mobile sites out there.

Edit: Some further comments: It's generally better to have a site that obeys the standards and thus plays nice with any client, than one that locks you into the hip designer's meth-addled decision. This site in particular works well with my extensions like VimFX for clicking links from the keyboard.

That's the thing - it shouldn't be necessary. I don't do that on desktop browsers; why should mobile devices be any different? If the site is not legible, I set the desired zoom once and I'm done. There's no need to go back and forth.

Now, I can't do that if the elements stay mismatched on mobile. I have to zoom in and then back when I want to interact with small elements - each time. It gets old when I have to click tiny links or upvote arrows more than a few times. It's jarring and not a good user experience.

> And, of course, using the same header pixel height for portrait vs landscape, making the latter practically unusable.

The floating header issue notwithstanding (I don't like them either), this is exactly why the web designers should tailor their elements to different viewports.

> It's generally better to have a site that obeys the standards

Yes, and that also includes accessibility guidelines. Compatibility with keyboard navigation is one of them, but so is the size and spacing of the controls, links, and buttons.

But I wasn’t comparing to the three or four mobile-optimized sites that satisfy all that. I was referring to the more typical millions that don’t.

And yes, given how bad they are, I’d much rather have suboptimal design that I can recover from with a pinch or a double tap than one I can’t.

What would you cite as an example of a mobile site that is more usable than this one?

This one being the Italian one from the submission or the Hacker News itself? I'm assuming the Italian one. Off the top of my head, sites with good mobile version and similar structure (lots of text and links) are Wikipedia and The Guardian. One tiny nitpick are tables with multiple columns in Wikipedia articles. This is a common struggle and I haven't found an elegant way of showing data-dense tables on mobile screens.

But other than that, all the elements on both of these sites are big enough, I don't have to zoom in, I don't have to scroll sideways, there are no floating elements, and they have distinctive style. They even work well with a dark mode add-on on Mobile Firefox.

I checked out Guardian.co.uk (assuming that's what you meant), and yes, it is a pretty well designed site that works great on and doesn't seem to even distinguish mobile vs desktop users. But still, this is about the only mobile site I couldn't find anything wrong with. This isn't the typical 99% site.

My further comments: https://news.ycombinator.com/item?id=22328505

The common definition of mobile device is phone or tablet. The common definition of laptop is computer. These despite the fact that phones and tablets are computers and despite the fact that laptops and even desktops can be moved. It’s pretty easy to find lots of examples of the common definitions. Here’s a good one: https://en.wikipedia.org/wiki/Mobile_device

The question of whether definitions matter when one sub-category or subset is a minority or majority... I’m not sure how to answer that. Why would a definition stop mattering just because something different is a small subset? I must assume that a categorical term includes everything in the category. If you don’t mean everything in the category, then don’t use the term that refers to the category. If you mean phone, then say phone. ?? Right? I’m confused why you would argue anything else.

All you needed to do then, and today, is make sure your HTML is valid and that you don't break things on purpose ("this site optimized for MSIE1.0" type of stuff) and your site will forever be mobile and any-other-html-rendering device friendly.

This is not one of those.

Time for a smooth, GPU accelerated 60+fps marquee implementation?

I'm sure a lot of you already know this easter egg, but if you search "blink tag" in Google, Google makes all the blink tags actually work (using JS of course but still)

https://www.google.com/search?q=blink+tag

But I use CSS, not JS.

I hadn't seen the old Google logo in years: http://www.drtsolutions.com/drtqueries.htm The search widget doesn't even use an <iframe>. Just a plain <form>.

Sorry, not sorry.

Love it!

I've had plans to rebuild it for the last 8 years or so, to make it better and slicker and easier to navigate (as it stands, my new papers are mixed together with my scribe notes from undergrad). But I never figured out how to achieve this without also requiring javascript or relying on tools that may not survive the next decade and that I cannot tweak to my needs without learning a new programming language (hello Jekyll, hi Hugo). Nor did I ever find the Right Way how it should be structured; move one thing to the front and something else gets harder to find. I guess it will survive me.

Makes me a lot less judgmental when I see another academic website that can trace its lineage back to geocities and angelfire.

https://www.lingscars.com/

That is what I miss the most about the old web. We wanted to build something better by sharing knowledge. And for a while we did. Then mainstream came and corporates took over.

Originally, Front Page had a four page license. It specified that if you use Front Page to create a web site, you cannot disparage Microsoft, Expedia and a list of several other Microsoft owned properties.

So with a license like that, I can't assume that any site created with Front Page is unbiased when it comes to a list of various Microsoft owned properties.

After the slashdot effect (long ago) Microsoft removed this from the license.

https://wiby.me/

Click the "surprise me..." link to see a random one.

http://toastytech.com/evil/index.html

https://www.berkshirehathaway.com/

This is really cool search engine :D

My favorite in High Scool was http://ripmat.it

That site is the only reason I managed to learn Math school

You need a dev team implementing Agile for react-native-ux with CI/CD capabilities and devops.

It's really frustrating when two browsers implement important parts the spec differently and push website developers to work around the behaviour one browser or the other with browser-specific code. It doesn't lead to sites being rendered differently as developers embrace the variety of user agents. It leads to people adding "This site is best viewed in Netscape Navigator" gif or "This application requires Chrome" on log in pages. Those are bad things.

I've been on the internet since the mid 90s. I'm well aware of what was, andit was that way because people then as now wanted things to look and act exactly like they wanted and not embrace that not everyone wants or needs your carefully crafted graphical design.

Or completely normal? Why shouldn't I bump up my minimum don't size to help read text and reduce eyestrain? Ditto for fixing low contrast text.

Deleted URL thanks to friendly advice

EDIT: checked the website, "add to cart" sends you directly to paypal and there doesn't seem to be any account system.

Still you should be careful with which communities you share this kind of information, hint: think of the H of HN

The funny thing is for years his home-made site was the top google hit if you searched for “hill's criteria” (See Hill's criteria of causation). His site is http://drabruzzi.com/

Frontpage may be old enough to consider it 'abandonware,' a quick Google for "free frontpage" has a lot of downloads including one from Kean.edu with an embedded key.

https://www.masswerk.at/demospace/relayWeb_en/welcome.htm

Slogan: "Microsoft keeps talking about Active Server Pages – We're offering Active Client Pages"

Mind the charts section, rendering graphs by outputting tables with tiny images using `document.write()`, since the canvas element wasn't even dreamt of. (Displaying charts was a tricky business, then. Usually these were rendered server side as GIFs, where they caused heavy load. The alternative were Java applets, which had an enormous effect on the client load and delayed page display quite considerably, while the JRE was starting up. Enter JS to the rescue…) Also, note the period design, including marquee tickers, custom fonts from GIFs, etc…

The big problem was always Accessibility-related semantics. Websites laid out in TABLEs were often quite confusing to screen readers, as TABLE has a lot of supposedly important semantics in how it should be read/engaged with and using a TABLE for layout follows none of them. (What does a table header mean in a layout? Most layouts wouldn't have good headers. How do you describe what a table column is supposed to be for without a column header?) It's a shame that narrative was never clear enough that Accessibility was always the big reason TABLEs were considered a Bad Idea for layout.

(Speaking of downloading a megabyte of data, I recall how long I felt that a 1.44 MB floppy was the best restriction for the size of an entire website. If it was bigger than a floppy you were probably doing something wrong. I stopped counting floppies a long time ago; that person might be ashamed at how many floppies a typical website downloads these days.)

http://flounder.com

Nothing wrong with readable content, regardless of the generator. In fact, I like reading his site precisely because it is speedy to load and render, and because it has content (unlike, for example, Apple's developer documentation).

My favorite editor of the day was a "hand coder" called Home Site

https://en.m.wikipedia.org/wiki/Macromedia_HomeSite

Some 'fancy' JS effects do not work on the page now, but it is still up. I forgot about and remembered it few years ago and checked it to find it still up. But I can't remember where could I login to see the files and what are the credentials so it makes me giggle that it will stay up for who knows how much longer as a small part of my past :)

http://dzigi.itgo.com

http://dzigi.itgo.com/o_autoru.htm "about author page" with a bio and pic haha

My favorite bit was the rollover buttons that used a Java applet to do so.

Here it was: https://web.archive.org/web/20030908174016/http://www.benibe...

But in 2005, I made a complete redesign: http://www.benibela.de/index_en.html

The backend went through a few reimplementations. Individually made html files (with front page express or something), a template tool written in Delphi, another template tool written in Java, a complete XQuery interpreter written in FreePascal

https://web.archive.org/web/20200214134509/http://www.fmbosc...

[0] http://marathon.bungie.org/story/

You can see the whole page in a single column, and just pinch zoom to the bit you're interested in to read/interact. Scrolling downwards and sideways to pan around works fine, super intuitive. The UX of this is so great, feels just like that original iPhone demo [1].

...why don't we do this again?

[1] https://youtu.be/vN4U5FqrOdQ?t=2530

https://www.seamonkey-project.org/

There is almost no javascript, and I have to say, it's done wonderful so far. I have tried Hugo to manage stuff, and a couple of others, but for a lot of blog type of stuff, html just works!

Taboola, Facebook thumbs, Twitter counters, and the like are the Hamster Dances of the 21st century.

Had I stayed with FrontPage, my life might have been simpler - porting 20 years of content is not simple - but I would have missed out on learning a lot of HTML, CSS, PHP, Python, MySQL, character set conversion, MySQL vs UTF-8, etc.

That html went straight to Geocities.

The feeling of power part of a minority of people who could actually publish something on the net was amazing.

My 21 year old site focuses on Windows NT and the upcoming Windows 2000 release. Back when MSFt focused on operating systems. Billg still in charge!

Jokes aside, the first thing I read was the sentence "here there is a java applet, sorry your browser doesn't support it" :D Which is funny, after all.

https://www.wonder-tonic.com/geocitiesizer/

"Make Any Webpage Look Like It Was Made By A 13 Year-Old In 1996"

https://i.imgur.com/XMwNRR3.png

I really hope something comes along that reinvigorates the public's interest in creating content that resides on their own website, rather than a walled-garden social media account.

I love the speed of the page! And seemingly nobody is eavesdropping me.

https://s3.amazonaws.com/simpleuseful/index.html

great website!

https://battlepenguin.com/tech/a-history-of-personal-and-pro...

Most of the content is still there, but it's been shifted between static pages, Rails, Wordpress and now Jekyll.

It's neat to see one of these gems still out there; a picture of the 90s web that's still functional and being used. Too many of these sites are lost; only available in the Internet Archives.

It's interesting because I'm sometimes sad I lost the code for some of those old versions. Those old early PHP and custom static generator codebases would be interesting to revisit with today's ideas, even if just to laugh about. (But also because I know there's probably not-great blog content lost to them.) One of the "custom static generators" I recall was actually a really early not-quite-SPA JS app. I remember it ran really slowly in browsers at the time and worse got slower with each new content added, but these days I wonder if it would seem fine on modern JS engines. (I've got a feeling about the only thing I'd need to change would be to swap `document.write(stuff)` for `element.innerHtml = stuff` and it'd perform quite well today.)