4 ms·

I'm a high-level guy, and I avoid using anything under 20 years in existence. All the easy problems are already solved and well-documented, and less likely to

I'm a high-level guy, and I avoid using anything under 20 years in existence. All the easy problems are already solved and well-documented, and less likely to break my code with a new release. I then try to write code in such a way that it would have worked 15 years ago and today both, working around platform changes. My current stack is Perl, HTML, CSS, SSI, PHP, SQLite, PGP, txt, and JavaScript. And yes, my sites do work in Netscape 2.0+, IE 3.0+, Lynx, Links, w3m, and with a few settings tweaks, also Mosaic.

giantDinosaur 6y ago
I refuse to write anything that supports any IE version < 11 on principle. And I will relish the day I can kill support for IE11, which is hopefully rapidly approaching. I admit I do enjoy a stack which includes text files, though.
- forgotmypw17 6y ago
  It seems to me like that stance does nothing helpful, only lets the developer off the hook of attempting something difficult and annoying. At the same time, it leaves human users who can't change their browser high and dry.
  - giantDinosaur 6y ago
    Worry not, in IE terms, 'rapidly' means 'within this decade', so I will unfortunately be supporting the last, not really venerable, version of it for a while. But even just messing around with CSS in old versions is painful: it's not just 'stack of 15 years ago' if you support IE6, it's also leaving out pretty much everything except the basics of text content, lest you spend really horrible amounts of time getting something to work.
    - forgotmypw17 6y ago
      You're right that a lot needs to be left out or put behind feature checks. But I can't say I've spent an inordinate amount of time tweaking for IE6 than most other browsers. I've probably spent the most tweaking work on IE3, Mosaic, and Netscape 2.
  - dvdkon 6y ago
    Less annoying work for me is something helpful in my books. If I can make my job easier at the expense of people using unsupported technology, I will, otherwise I'd be stuck supporting that one guy who refuses to move from Mac OS X 10.4.
  - mewpmewp2 6y ago
    It is a business decision. Deliver a feature faster to 99.9 percent people as opposed to later for 100 percent. Neither is right in all scenarios which makes the whole argument pointless without specific scenario. There's a slider you can move with support percentage and time efforts required to make it happen. It is about balancing trade offs. Taking one fixed stance will just make you inflexible.

giantDinosaur 6y ago

I refuse to write anything that supports any IE version < 11 on principle. And I will relish the day I can kill support for IE11, which is hopefully rapidly approaching. I admit I do enjoy a stack which includes text files, though.

forgotmypw17 6y ago
It seems to me like that stance does nothing helpful, only lets the developer off the hook of attempting something difficult and annoying. At the same time, it leaves human users who can't change their browser high and dry.
- giantDinosaur 6y ago
  Worry not, in IE terms, 'rapidly' means 'within this decade', so I will unfortunately be supporting the last, not really venerable, version of it for a while. But even just messing around with CSS in old versions is painful: it's not just 'stack of 15 years ago' if you support IE6, it's also leaving out pretty much everything except the basics of text content, lest you spend really horrible amounts of time getting something to work.
  - forgotmypw17 6y ago
    You're right that a lot needs to be left out or put behind feature checks. But I can't say I've spent an inordinate amount of time tweaking for IE6 than most other browsers. I've probably spent the most tweaking work on IE3, Mosaic, and Netscape 2.
- dvdkon 6y ago
  Less annoying work for me is something helpful in my books. If I can make my job easier at the expense of people using unsupported technology, I will, otherwise I'd be stuck supporting that one guy who refuses to move from Mac OS X 10.4.
- mewpmewp2 6y ago
  It is a business decision. Deliver a feature faster to 99.9 percent people as opposed to later for 100 percent. Neither is right in all scenarios which makes the whole argument pointless without specific scenario. There's a slider you can move with support percentage and time efforts required to make it happen. It is about balancing trade offs. Taking one fixed stance will just make you inflexible.