+ Google Maps in 2004 and dragging the map interactively around. This was a quantum leap beyond Mapquest's page reload and reset with cumbersome arrow buttons. This was a paradigm shift that let me explore a geography better than any book atlas. I gave away all my atlases

+ MS Window Media Player's ability to cleanly accelerate playback to 2x,3x,4x of audiobooks and tutorial videos for slow speakers. MS Windows 7 had this long before Youtube's player had a 2x playback option.

+ SQLite library : more than 10x improvement since I came from old school of writing custom formats for persisting data. No more dumping memory structs to disk or writing b-trees in C Language from scratch.

+ C++ STL in late 1990s. Instantly reduced need to write custom data structures like linked-lists or in-house string libraries for common tasks

+ VMware in 2000s : more than 10x productivity enhancement because I can play with malware in a virtual software sandbox instead of tediously re-imaging harddrives of air-gapped real physical machines

+ Google Chrome in 2008 : 10x quality-of-life since misbehaving websites crashing don't bring down all the other tabs in my browsing session like Firefox/Opera.

I probably have more than a hundred examples. Some software tech 10x improvements are more diffused. Reddit+HN websites are a much better use of my time than USENET newsgroups. Youtube with recordings of tech conference presentations I can watch at 2x+ is a better used of my time than physically traveling to the site.

Adding to this: just browser tabs themselves were a 10x improvement for me. I had actually forgotten what the world was like before tabs - a whole lot of unsortable windows, and a lot of clicks of the back button.

It was a godsend to be able to open new links in a tab, and to be able to see those tabs organised neatly in front of you.

Unlike today, back then Firefox had a clearly expressive value proposition: Use this! It has tabs! It will change how you browse the web!

Now the only value proposition is some wishy-washy privacy stuff that is much harder to sell people on, even if it's in their best interest.

And although browsers are no longer distinctly better than each other, I still donate to Mozilla.

What a fun time.

https://github.com/marklieberman/foxygestures

https://otter-browser.org/ (Tools → Preferences… → Advanced → Mouse → [X] Enable mouse gestures)

Opera added true tabs some versions later, while still hanging someway on the MDI-tradition.

I think I do this as a self-remedy for my ADHD, I am likely to allow an interruption to disrupt me but I do need to close the loop on whatever I was working on before an interruption. A window or set of open tabs is enough of a reminder to help me close the loop.

Tree-style tabs [0] in Firefox help to keep a train of "research" together.

[0]: https://addons.mozilla.org/en-US/firefox/addon/tree-style-ta...

Then I sometimes, open links from comments, or Wikipedia etc.

Today i have more than 50 tabs open just starting from HN.

Some stories when i read I close, but sometimes when I think i need to reread or save for later.

After the week i usually have around 150+ tabs that i have left for later, I do the triage and I either save to my notes (like interesting, os dev articles, or rust or postgre optimization tips ...) or close.

And thats just for HN.

They'll still use Chrome or Edge/IE, but will use NordVPN or ExpressVPN after seeing their favorite YouTuber claim that the VPN protects their data and gives them privacy...

...while still not using an ad blocker, which makes the VPN almost entirely worthless from a privacy perspective. At most, it blocks your ISP from seeing what you're doing.

In fairness, that is a nontrivial privacy win for a decent number of people.

I fully believe the extensions were really a huge part of Firefox' moat.

I still miss some features in Opera like mouse gestures. No, plugins and add-ons can't reproduce the responsiveness of a native implementation, they all fall short.

On a sidenote, I stopped using Opera when they included a torrent-client in their webbrowser. The amount of bloat was staggering.

Spending 2-5 days setting up a development environment, then archiving a copy of the whole VM made some of the crappier setups usable. Back before rented software (including the OS) that meant one person could grind through the whole OS/tools/IDE/libraries stack and get something we could all use. I've broken software protection to make this work, because it's just such a huge productivity win.

Being able to have a whole test matrix worth of systems virtualised also helps. One place we interacted with MS-Office, so the matrix was Win95/98/Me/XP/2000 (etc), then three versions of Office {cries}. It would have been just unreasonable as a small company for us to have and maintain 2-3 copies of that matrix as physical machines.

It comes in very handy for those rare times when a major customer that (for some reason) insists on sticking with an ancient, obsolete version of your software desperately needs a critical fix.

An essential trick if you have long-lasting products. I've been able to (and asked to!) make fixes in ~2015 to code that was written in Turbo Pascal 6. With firmware for embedded devices it's more necessary and often also harder, because often the hardware to flash the firmware doesn't work with new computers. Or you end up with a chain of USB-Serial adapter to serial-to-weird adapter to "programmer board" to actual device... but I knew that when I carefully packed everything into an antistatic bag 10 years ago :)

Aaahhh. The year Google launched, a friend and I were sitting next to each other, at our PCs. Both of us were techie types and into innovative stuff, although working in a software services bigco at the time.

I casually said to him: "I came across this new search engine a few days ago while browsing for interesting stuff. They say they are fast(er than others)."

Gave him the URL. He typed it in, ran a search, saw the results and the time, like 0.0x seconds or so. And muttered "That's fast".

It was Google.

Copyright never has to be declared, and I think in many ways Google is responsible for websites having copyright in footers not realising it’s not a legal requirement.

In typical area Google has simply much better data - and that is before interface optimised for selling ads about POIs and therefore displaying POIs quite well.

I map a lot in OSM, and POIs in my city are still light years behind Gmaps. And even with StreetComplete (an Android app that I recommend) that made adding and resurveying opening hours data easier, this info is often missing/outdated :/

There were open source coding tools in the early 90s (a lot of the GNU tools, including Emacs and GCC, were first released in the mid-to-late 1980s.)

Apologies for the shameless plug--we're on IG @notasatellite if you're interested in seeing some examples :^)

Edit: also, nobody can ever sunbathe in peace again.

Most airports are zoned industrial and located within or on the edge of cities and towns, so we can provide more frequent updates of areas that are of greater value to customers monitoring supply chains, construction/site development, estimating traffic flows, etc. High-revisit is equally important at cruising altitude over much of the country where demand for agricultural/environmental monitoring, crop yield data, etc. is of similar interest.

All this to say coverage is a known limitation, but based on those reasons I think (hope) we'll become the yin to satellite imagery's yang.

Is technology too widespread? Do we need moral courses, in addition to tech ones?

The world is constantly changing and we need better, faster, and cheaper methods of measuring those changes. We can respect (and actively lobby for) privacy while obtaining these results at the same time. Morality and technology should not run parallel to one another, they should both be woven into the products we use every day.

I'm pretty certain there were third-party players that could do increased playback speed with unchanged pitch before Windows 7.

Otherwise it's the #1 browser by usage by far, which is saying a lot considering it doesn't come preinstalled on Windows or on Macs, so all those users are making a deliberate choice to switch.

So still the hero outside of HN.

Ever used for example YouTube with an alternative browser?

It's buggy, it's slow (and that's on purpose; Google puts regularly quite some engineering effort into using web features that don't work well in the last independent competing browser). But those Google pages have a big banner saying it will work better in Chrome, and asking the users to "try".

That strategy works very efficiently as Google controls the sites most average people use the whole time.

That's one of the reasons why Google's monopolies need to be broken by regulation. Actually they're over-due for a break-up.

https://addons.mozilla.org/firefox/addon/disable-polymer-you...

Yes, it's a work-around, not a long-term solution and does not help with the underlying problem. Spread the word and enjoy it while it lasts.

With adblocker I have nothing to complain about.

The reason I understand their comment is because there was a period of time when Google was so cool that people wore Google t-shirts without having ever been affiliated with Google. You could find random college students wearing a Google t-shirt like they would a band t-shirt.

Every developer from around 2006-2008 knows what I'm talking about. Debugging JS in IE6 was like trying to build a house blindfolded with both arms tied behind your back. Firebug is when JS went from just a web augmentation toy that could silently fail and your web page would still mostly function to becoming a critical function for a web page (many will see this as all a big mistake).

An accessible UI that honors the platform specific conventions and integrates into the OS environment?

Ever built an user-experience atop ideas like "form follows function" and "don't make me think", that has beautiful design at the same time?

I actually question that there are more than a handful Web-UIs been built in that way, ever, IF actually any!

Yes. That's what I currently get paid to do.

> I mean with all that ARIA stuff, that really works for the blind or other disabled people?

Yes. If I didn't do that then we'd be sued by our customers for not being accessible.

> An accessible UI that honors the platform specific conventions and integrates into the OS environment?

Web-applications run in the browser, independent of the host OS. While web-applications do tend to adopt some OS conventions (such as having a "close popup" button in the top-left or top-right corner, web applications on-the-whole don't really ape after Windows or macOS' conventions and the past decade of post-Windows/post-macOS web-applications UX development shows that following desktop UI conventions really isn't necessary.

> Ever built an user-experience atop ideas like "form follows function" and "don't make me think", that has beautiful design at the same time?

Again, yes. (Beauty is subjective, of course - I've been told my work is "gorgeous" by my boss, so I've got at least one endorsement there)

> I actually question that there are more than a handful Web-UIs been built in that way, ever, IF actually any!

Fewer than I'd have liked, I admit. At least with today's "cleaner" look it's easier to visually design something that isn't an eyesore.

I appreciate a huge problem is that since the 2010s the learning-curve for front-end web-work has steepened considerably, and other barriers-to-entry have been introduced with no sign of them going away. Since the 2010s, when SPAs and modern CSS (flexbox, grid, responsive layout) came into being you might have noticed that fewer web dev clients today are making remarks like "my 12yo nephew could have made that!". Not to sound nostalgic, but in the late-1990s through the mid-2000s one could very easily be a very competent web-designer getting-by in Photoshop, Fireworks and Dreamweaver without ever needing to learn HTML and JavaScript (not that there was much to JavaScript back then either) - today it's increasingly essential to have at least an undergraduate CS degree to even understand how to correctly use React.js or Angular - and be comfortable with a command-line terminal. Project requirements for resolution-independent and form-factor-independent ("responsive design" - though I detest the term) web design means that the days of fixed-layout Photoshop-first web-design work and the age-old Image Slicing tool are over: tools originally designed for WYSIWYG print layout and graphic design are insufficiently expressive to allow someone to intuitively visually define how a CSS-driven layout and document-flow should work. In ye olden days it was straightforward for a relative beginner to grok how <table> could be used to make a semi-flexible layout - but explaining how CSS's grid's `auto-fit` works to the same person is impossible. And so on and so on.

Web-design has gone from the approachable place where COBOL was ("write business rules in plain-English!") to being a hallowed and exclusive techno-religious cult. I can't personally complain because I appreciate the job security I now have, but I am concerned it may lead to the web becoming less and less accessible to independent self-publishers who instead flock to much easier-to-use, but proprietary, walled-gardens like Facebook pages - or to web platforms that hide the complexity entirely, like Wix, and SquareSpace.

Meanwhile, beauty is in the eye of the beholder. The modern webtech trends are offensive to my eyes - in addition to being ridiculously compute- and visual-space-inefficient.

If you’re referring to the oft discussed “information density” issue, my goodness, scroll a little. That spacing is good for usability and, yes, accessibility. Those larger action targets and the space between them are not only good for us with vision impairment but for people whose only computing device is a phone.

That's an anti-solution. Scrolling is bad for your brain and reduces comprehension - it makes it harder for your brain to figure out what's going on.

There's a continuum between "everything on the screen is 6pt text with no spacing" and gigantic mobile-UI buttons on a desktop environment - and modern webdev errs far too close to the latter.

> That spacing is good [...] accessibility.

Big buttons with small text and no borders - which are part of the design trend - are significantly worse for accessibility.

> That spacing is good for usability

Spacing in general? Yes. The ridiculous amounts of spacing that modern webdev encourages? Absolutely not. There are diminishing returns, and modern webdev goes from "reasonable" into "unreasonable" territory.

> Those larger action targets and the space between them are not only good for us with vision impairment but for people whose only computing device is a phone.

My argument had to do with desktop platforms. You can build websites that are usable on phones while being efficient on desktops, either by building two separate sites, or through responsive design - but modern webdev doesn't, instead choosing to build desktop sites that have all of the aforementioned problems for no good technical reason.

> There's a continuum between "everything on the screen is 6pt text with no spacing" and gigantic mobile-UI buttons on a desktop environment - and modern webdev errs far too close to the latter.

This is probably not out of laziness or lack of consideration, but because pixel accurate pointing devices also better serve a wider range of desktop users when there’s larger targets. If you’re upset by this, you’re better off focusing on improving vision correction and motor skills than complaining about designs that accommodate more people than just you.

> Big buttons with small text and no borders - which are part of the design trend - are significantly worse for accessibility.

I disagree with your interpretation of the design trend. What I see is buttons with text consistently sized, and with padding fitting to the container to halve the cumulative padding while providing the same tappable area.

> Spacing in general? Yes. The ridiculous amounts of spacing that modern webdev encourages? Absolutely not. There are diminishing returns, and modern webdev goes from "reasonable" into "unreasonable" territory.

This is apparently entirely a matter of experience and opinion. But I do the majority of my web browsing on my phone except when I’m doing dev, and I feel exactly the opposite. Stuff is too crammed in. When I do browse on my computer I don’t see more spacing, just larger sizes of everything.

> My argument had to do with desktop platforms. You can build websites that are usable on phones while being efficient on desktops, either by building two separate sites, or through responsive design - but modern webdev doesn't, instead choosing to build desktop sites that have all of the aforementioned problems for no good technical reason.

What you’re describing is the baseline principle of responsive design. It should be available on every device. If you’re using a touch interface on a tablet, no one can know for sure you’re not on a desktop. So, big touch targets are still necessary for those users.

1. Asking people to show a little empathy to others (eg use your scroll wheel so people can benefit from reading a thing or clicking it at all)

2. Asking people to show a little empathy to others (eg recognizing that people who have violent ideologies are dangerous and don’t deserve free mandatory amplification from others’ resources).

3. Asking people to show a little empathy to others (eg not trashing people’s fun/exploratory/educational/hobby projects).

I don’t get downvoted for anything else. I’m sometimes surprised for the silly stuff I get upvoted for. But give half a damn and it’s just like the hateful crowds on Slashdot and 4chan and every platform they’ve flocked to, who just hate seeing anyone give a fuck about anyone or anything.

Bring on the downvotes!

It reads like you had a bone to pick with the information density argument, and just wanted to get into a flamewar when you saw someone who perhaps disagreed with you. I expect people weren't downvoting empathy. I think they were down voting a rude attempt at starting an off-topic flame war.

I use my tablet occasionally for Numbers, but it never even occurs to me to try it on my phone.

Visual Studio (even back when it was called Visual Interdev) supported first-class script debugging with Internet Explorer going as far back as Internet Explorer 4. Ditto cscript/wscript.

It just wasn't popular (and few people knew about it) because most people doing front-end web-work _back then_ weren't using Visual Studio, and in general most people weren't doing back-end web-work in Visual Studio either because (pre-ASP.NET MVC), ASP.NET WebForms is, was, and ever-shall-be, godawful.

If I wanted to have a editable table (datagrid) control it literally took about 20 minutes and I had something working and people could use it.

The problem with it (much like Angular which btw is basically webforms for JavaScript) is that it required you learning how the event lifecycle worked properly. Whereas other things at the time were web scripts and you could just hack against.

It of course had a lot of problems (like everything on the web at the time) but for what it was actually intended for, it was actually really good.

Other complaints about WebForms weren’t inherent to its architecture and should have been corrected early on, such as the lack of testability and over-use of [ThreadLocal] storage, and the nigh-impossibility of running WebForms outside of IIS, but these were never properly addressed by Microsoft, instead we had ugly band-aids like “BaseHttpRequest” and “HttpRequestWrapper”. Le sigh.

While the HTML is awful in earlier versions was IME of no concern. Most intranet apps just need to be functional not slick. I am sure it served different HTML based on the user-agent but I could be mis-remembering now as it was well over 15 years ago.

The lack of being able to run it on anything other than IIS isn't a concern. Most places using WebForms were Microsoft shops and whatever your opinion of IIS and Windows server maybe they weren't going to be running their ASP.NET app on a Linux server.

Most of the problems I've encountered was when people tried getting around the framework itself and rebuilding what already worked quite well within the framework (many people used to use large string builder objects in the code behind files in the page load event rather than using Web Components and building their custom HTML in there, I suspect it was because they didn't understand the Page/Component lifecycle).

I'm actually trying to get away from using .NET entirely (I am bored of the language, the frameworks and most importantly I don't like working with the developers who can't do anything outside of Visual Studio to save their life). But I do think the framework get unfairly maligned because of the quality of programmers that were using it. It is the same with VB.NET, the language isn't the best but the RAD aspect of it hasn't been bettered by anything IME.

It did - but the "different HTML" you refer to was HTML4 for IE5.5+ or HTML3 to browsers it didn't recognize. Even by 2001 that was a bad idea, and by 2004 Firefox was leagues ahead of IE6's support for HTML and CSS features yet ASP.NET WebForms defaults to rendering HTML3-era HTML to Firefox.

...and don't forget all of the problems inherent in user-agent sniffing. Users with too many third-party IE toolbars or shovelware on their computers would see things break (because said third-party software would frequently alter IE's default user-agent string to add their own product-names, which broke things).

> The lack of being able to run it on anything other than IIS isn't a concern

It was a *huge* concern because it meant that web-application code could not be run by automated testing tools! That was one of the design-objectives when OWIN was introduced: for greater testability (for unit and integration testing). Otherwise the only way to test WebForms applications was by having a dedicated web-testing farm with web-browsers open on the desktop driven by custom-written automation tools - that just wasn't an option for smaller shops. And Visual Studio didn't add built-in unit testing support until 2005 (only for Enterprise edition), and 2008 (or 2010?) for everybody else.

Another problem was that in the days of WebForms 1.x (before .NET 2.0) the only way to run ASP.NET applications, even for development, was by having IIS installed - but IIS was not available for Windows XP Home Edition (ASP.NET 2.0 introduced the "Cassini" local development web-server, but it was severely lacking and did not faithfully recreate the IIS environment, and IIS Express wasn't introduced until around 2008). People doing hobbyist development at home had to either pay to upgrade to Windows XP Professional (to use the rather limited IIS "5.1") or apply a variety of crude registry hacks to trick the Windows 2000-era IIS 5.0 to run on Windows XP Home Edition.

> Most of the problems I've encountered was when people tried getting around the framework itself and rebuilding what already worked quite well within the framework

What works "quite well" is subjective. ViewState just doesn't scale and is unsuitable for public Internet websites because it balloons the rendered page-size (e.g. if you have an <asp:DataGrid>, used as-directed such that it's only loaded on the initial page laod) then the entire data-grid's data is persisted in ViewState, which practically quadruples your rendered page-size (due to all the hidden control state) - which was unacceptable in the days when 56K modem use was still widespread (even through to ~2006+). Disabling ViewState was essential for any public web-pages, which increased the amount of work required to get things to _just work_. I could go on...

Intranet sites were run on highly locked down machines that were running IE. Don't pretend everyone was running their own browser on their machine. As I said it was intended for intranet sites, all the documentation and all the examples at the time clearly showed these user cases.

> ...and don't forget all of the problems inherent in user-agent sniffing. Users with too many third-party IE toolbars or shovelware on their computers would see things break (because said third-party software would frequently alter IE's default user-agent string to add their own product-names, which broke things).

So they were running third party things and it broke something else that had no knowledge of them. If someone runs hundreds of chrome extensions and it breaks my site, I wouldn't bother supporting them either. The situation isn't any different.

> It was a huge concern because it meant that web-application code could not be run by automated testing tools! That was one of the design-objectives when OWIN was introduced: for greater testability (for unit and integration testing). Otherwise the only way to test WebForms applications was by having a dedicated web-testing farm with web-browsers open on the desktop driven by custom-written automation tools - that just wasn't an option for smaller shops. And Visual Studio didn't add built-in unit testing support until 2005 (only for Enterprise edition), and 2008 (or 2010?) for everybody else.

Almost none of the shops were doing automated testing at the time. People barely do it now in the .NET space.

>Another problem was that in the days of WebForms 1.x (before .NET 2.0) the only way to run ASP.NET applications, even for development, was by having IIS installed - but IIS was not available for Windows XP Home Edition (ASP.NET 2.0 introduced the "Cassini" local development web-server, but it was severely lacking and did not faithfully recreate the IIS environment, and IIS Express wasn't introduced until around 2008). People doing hobbyist development at home had to either pay to upgrade to Windows XP Professional (to use the rather limited IIS "5.1") or apply a variety of crude registry hacks to trick the Windows 2000-era IIS 5.0 to run on Windows XP Home Edition.

So on an operating system that was intended for consumer use, they couldn't use advanced stuff like IIS that the home user wouldn't have any use for? Seriously?

> What works "quite well" is subjective. ViewState just doesn't scale and is unsuitable for public Internet websites because it balloons the rendered page-size (e.g. if you have an <asp:DataGrid>, used as-directed such that it's only loaded on the initial page laod) then the entire data-grid's data is persisted in ViewState, which practically quadruples your rendered page-size (due to all the hidden control state) - which was unacceptable in the days when 56K modem use was still widespread (even through to ~2006+). Disabling ViewState was essential for any public web-pages, which increased the amount of work required to get things to _just work_. I could go on...

None of this was intended for sites on the internet. I was specifically talking about the RAD tooling. Yet you seem to be talking about things it was never intended to do at the time.

I’ll add that to the other valid reasons that you mention.

Support for CSS "debugging" was completely absent, yes.

JS ignores the value of every statement in a comma-separated expression except the last one. So you can do trash like this:

    const foo = (bar) => (
        console.log(bar),
        someComputationOf(bar)
    );

I take stackoverflow and blogs for granted.

I did have a hand-rolled blog back then (The Hole Report) but was busy writing about magic tournaments and didn’t think anyone else cared about javascript hacks.

Fortunately another bad feature of IE was to alert() the errors, so customers were aware of each of them and could easily send us the bug back...

This bank employee used PrintScreen to print the screenshot on paper. He the successfully faxed it to his email, zipped it and uploaded it to our bugtracker. I had the zip of a .tiff of a scan of a printed screen. I still wonder whether he did it because he was upset, or whether it was a usual workflow.

I worked at Amazon during this time on our custom web server and before that I had been using telnet to hand type my commands or various perl scripts I wrote to emulate a browser's requests. And... ugh, tcpdump to figure out what exactly browsers were sending before they got to apache.

Firebug was like magic!

It's still really good!

[0] https://www.charlesproxy.com/

https://www.youtube.com/watch?v=XyALl2EILQk

To be clear I mean that Visual Studio had a C/C++ debugger but outside of that most languages that I used in any other situation were missing good debuggers.

1. The "hidden" element at the root of the IE DOM tree, only accessible with "*" via CSS

2. inline-block was broken on IE6 (but fixable with hacks), and no transparent PNG support.

3. The outline CS property was implemented the same as background in IE

Best of all was the dog slow IE 6 JavaScript interpreter, which was like 50x slower than Firefox and IE 7+.

TBH I found cross platform development during that time easier than when smart mobile phones came out. There was about 20-30 slightly incompatible forks of the Android Browser/Webkit and the processors were slow and everything was JS. Blackberry OS was still a thing. I also don't miss the problems with iPhone 3GS and 3D background layer flickering.

Also programming cross platform at the time showed me how to write lightening fast JS. That has made me a lot of money when people come to me to fix their crap web apps.

It was a DXImageTransform Alpha filter. Complete pain to use.

In the recesses of my brain somewhere is a memory that it was related to ActiveX, and/or the CSS filter property. You set some special filter value that invoked ActiveX? Maybe I'm remembering incorrectly but if I think about it too deeply I might start screaming and never stop.

I don’t miss those days.

Now you can "copy URL" or "copy URL parameters" but there's no way to copy them all in one go. You need to manually combine them in an external text editor which is annoying.

Have been a professional developer since 1999 - no idead what you're talking about.

So not a very good example at all, in fact quite the opposite, it just happened to ride the back of the anti-M$ wave and wasn't at all innovative, copying its features from already existing products.

Conversely, though it was free, IEDevToolbar was only really advertised to MSDN subscribers, so never got much penetration, especially as by then everyone hated IE6 and a lot of Devs worked in Firefox first.

But my company only supported IE6, and when we finally started supporting Firefox, firebug was an annoyingly sub-par experience when debugging js.

Even Chrome's early Dev tools had some sorely missed features when it first came out, as far as I can remember it took them years to support being able to just hold your mouse over a variable and see its value. And because it was a web-page about a web-page you got all these weird bugs. And the CSS editor was (and still is) super annoying with its attempts to cut up your text.

On top of that visual studio also had a JavaScript debugger, I'm sure there were plenty more paid tools you simply didn't know about.

<https://web.archive.org/web/20051223164847/https://www.mozil...>

<https://web.archive.org/web/20050206082145/http://www.mozill...>

<https://web.archive.org/web/20050206185242/http://www.mozill...>

(Joe Hewitt created DOM Inspector and checked it in to CVS while working at Netscape. Robert Ginda had separately created Venkman. Firebug used the XPCOM interfaces that had been created to allow for Venkman's debugging capabilities, but IMO was always inferior to the much more powerful Venkman, even if Firebug was slightly prettier to look at. PS: shame on Mozilla for breaking those links. Do you even know how to Web?)

> Firebug came out AFTER IEDevToolbar

I'm not sure that even if you focus purely on Firebug and ignore DOM Inspector and Venkman that this is even true. Do you have a source for that?

Absolutely not.

> Firebug wasn't just prettier; it was much more usable

Venkman made some debatable decisions about UI defaults, as is the case with a lot of tools built by old school programmers trying to solve their own problems, but it was more customizable, flexible, and powerful (as is the case with a lot of tools built by old school programmers...). Aside from Firebug's template-based rich console, every feature implemented in Firebug's debug pane was implemented in Venkman, except Venkman gave you even more latitude and control. Firebug's debug pane was a basic UI over a subset of Venkman's APIs, after all, as previously mentioned. It was only many years later (much closer to Firebug's death than its birth) that Firebug got some improvements like showing a variable's value in the source window while stopped at a breakpoint without having to type it into the console (or set a watch on it, or look at its activation record entry). Venkman never had that, but it pales in comparison to all the things that Venkman could do that Firebug did not.

Firebug made its own share of dumb decisions, and the degree of dumb in those instances was higher.

> [Firebug] focused on actual website code

I'm not sure how it could be "focused on actual website code". Venkman was a straightforward JS debugger. (The only way this could possibly make sense is if you're referring to all the stuff baked into Firebug outside it's debug pane—style sheets, live view of document nodes, cookies, and so on; all things outside the purview of a language debugger—in which case it becomes an apples and oranges comparison. It would make more sense to criticize DOM Inspector for any of those things than Venkman. And once again—there were plenty of dumb decisions by Firebug in that comparison is concerned.)

Yes, you're focusing on the debugger only. The fact is, most people simply did not use Venkman since it was hard to understand how to use it, for what context it was meant. Firebug tied the debugger into a wider context, making it more accessible, and reached a level of popularity that Venkman never had.

It may very well have been the case for a small number of MS centric devs, but for the large majority of users, it was Firebug that really changed the game for the bulk of Frontend devs back then.

While I agree that IE's devtools had more features regarding xpath integration, you'll also had the problem that it was based on libxml (yes, the reason trident was exploitable for decades, and probably still is).

IE's devtools didn't have access to the DOM and only had access to the HTML/SGML/actually XML representation _before_ it was parsed into the DOM.

This gave you hundreds of error scenarios where debugging user events was simply impossible if they caused the DOM to change, something like adding a node or debugging a parentNode was impossible in trident.

And oh how often have I seen bugs in websites that were relying on specified flow roots that behaved differently in trident. Something like an unclosed <p> in the wrong place could easily mess up everything in trident and switch it to quirks mode.

Remember IE was exploitable via a parentNode.remove(parentNode), too? The hooks for devtools was the underlying reason.

I am not sure why you claim that IE had superior devtools experience. You must have done a lot of ActiveX related development, because everything else was impossible to debug in my opinion.

The best thing MS did was to create the Edge team that tried to refactor trident, and soon realized that it's impossible and instead started over from scratch.

It's not who was first, just who seemed 10x better than the next best option.

1. Automatic device discovery and driver installation (e.g., with USB devices (also USB device categories, etc.)). Instead of trying to find a driver, things just worked.

2. Automatic updates. Keeping everything updated, largely, fell into the background.

3. Graphical integrated development environments (IDEs) for software development. I realize editors can be contentious, but tab completion of variable names, automatic identification of methods within scope, syntax highlighting, easily dropping breakpoints, etc. are, in my experience, wonderful improvements on productivity.

4. What you see is what you get (WYSIWYG) text / image editors. Thankfully, I did not spend much time in the prior era, but it was, at times, maddening to get something to format correctly.

5. Ad blockers / reader modes. Again, I know these can be contentious, but, for me, these reformatting services are sometimes the only way to make some websites practically readable.

I strongly second:

-The rise of memory-managed languages (e.g., JAVA, C#, etc) with pretty robust default library sets, especially for string manipulation, graphics, and network operations.

-Moving map software, especially for mobile GPS mapping.

-Spreadsheet software.

-Being able to easily search for answers to fairly technical programming problems, compiler errors, etc. along with better access to online documentation.

I remember well when installing Windows went from "make sure you have all the driver CDs before you start" to "just make sure you have the network card driver and the disk driver (if needed)" and then it went to "as long as you can connect to the internet Windows Update will get everything".

Before you had to get on the internet and find all the driver files yourself. The last hold out was graphics card drivers IIRC.

Fun story. Had Windows 7 installed on an old HDD. Decided to build myself a new PC, so I got all the parts (completely different setup than what the HDD had been in), put them all together, connected the HDD, and powered it on to see what would happen. I was shocked to see that Windows booted just fine with the new setup, like nothing had changed...

I remember trying to do a PC overhaul with Windows 2000. I swapped out the motherboard, RAM, and CPU, and Windows would fail to boot, crashing with an INACCESSIBLE_BOOT_DEVICE error. IIRC, I managed to recover without wiping the drive and doing a clean install by putting back in the old mobo/RAM/CPU, booting up, and swapping the IDE driver from a motherboard-specific driver to a generic IDE driver (Which comes at a signifcant performance penalty because I lost UDMA support), then swapping back to the new mobo. It booted fine after that, and I was able to install the proper motherboard drivers to get UDMA support on my IDE drive.

Using web-based email clients was a nightmare before Gmail. They had limited storage space, and the UX was pretty bad, they were hard to search, etc. You spent all your time figuring out what you wanted to delete, or seeing your emails bounce when people had full inboxes. If you didn't log in for a while, your account would disappear.

And then suddenly, you got a GB of storage. For free. No questions asked. And its UI was simple and easy-to-use. And you could search it.

A lot of other products are 10x better in individual areas. For instance, Google Sheets was much more portable/shareable than Excel when it launched. But even today there's no comparison, Excel is superior for actual spreadsheet functionality. But Gmail was better on every axis, even against local clients like Thunderbird and Outlook.

Also don't forget that Gmail at the time had the most intelligent spam blocking algorithm compared to AOL/Yahoo/Hotmail/etc.

It was a big enough deal that some observers that switched to Gmail considered the email spam problem as "solved" because Gmail seemed so good at it. (On the other hand, many independent people trying to run their own SMTP servers think that Gmail is too aggressive with spam filtering because it also blocks many legitimate senders with low/unknown reputation.)

The response was:

  451 Currently Sending Spam See:
  http://www.sorbs.net/lookup.shtml?209.85.215.41

Other providers were probably using expensive NASs with huge profit margins built in. Google was using thousands of the cheapest crappiest commodity parts because it was all triple redundant... and it worked faster because the network was really fast and multiple computers could stream different parts of the same file to clients.

Very, very influential reading back in the day, and still interesting.

Then Google dropped their MapReduce paper: https://static.googleusercontent.com/media/research.google.c...

Which quite literally paved the way for modern data processing, and works extremely well with the Google Filesystem architecture

Gmail was not just 10x. I think it redefined what a good web based email experience could be. I think it completely changed what people realized and expected the web browser could be from an interactivity standpoint.

Email before always looked like how Twitter threads do today.

I guess there are probably a lot of people here who are too young to have ever used those early versions. You also had to scrounge forums for an invite code.

I don't even speak italian!

Someone will have the idea and sign up for 5-6 things all in one burst, which usually inspires my outreach.

For those who don't remember: That was around the time when Yahoo offered 6MB, some others only 2MB.

They say 2 MB Hotmail, 4 MB Yahoo. Gmail went straight to a gigabyte.

http://web.archive.org/web/20070708004553/http://richard.jon...

http://libgmail.sourceforge.net

https://pramode.net/articles/lfy/fuse/pramode.html/

Best April Fools joke ever.

That's still true for gmail, but the time is more reasonable at two years.

Email is still heavily used for business-to-business communication between humans. Talking about business matters is still more natural via email until the participants know each other well enough to switch to texting.

But yes, for personal communication, friends & family have shifted from email to phone texts. E.g. my friend who graduated from college in 1990s used to communicate with his parents with 100% email but now it's 100% text messaging. Email is too much friction for personal comms.

Looking at my password manager I've got ~260 logins right now and keep in mind that I don't do social media and try to avoid creating accounts as much as possible (and delete the ones I don't use for a long time), so the average user is likely to have a lot more accounts.

Even if each one of these companies only spammed once a week (most will do more frequently if you let them), that'll already significantly outnumber the amount of legitimate e-mail I receive.

Gmail took XMLHttpRequest and its ActiveX fallback (we used to call this “comet”) and proved the world that we can ship a robust app inside a web browser.

It was well designed, had no ugly banners like Hotmail did, it was really fast, simple and working like a desktop app.

There was POP3 before this of course, to keep all your mail locally and empty out the server box. But that only works if you have a single computer that you check mail from. Even back in 2004 when Gmail launched that was a non-starter for me, I had email at home and at school.

I've never cared for invite only stuff, but Gmail really was a total revolution when it came out.

No.

Gmail did not suck badly enough to be merely 10× better than Hotmail.

Gmail was lightyears beyond other early free webmail services.

I think people who have addresses there must just use them as throwaways as they don't seem to have much utility. You can be a small email sender with everything right, clean IP, on no block lists, SPF, DKIM, mta-sts. You can have no problems with any other major email provider. You can be signed up to SNDS. And they will just routinely block your IP for no reason and it will not even show up in SNDS and you can't resolve it through the tools they provide to mail senders on SNDS. So you have to go through this stupid process of filling in a support form which gives an automatic reply saying there is nothing to fix and you can't reply. But you do reply and then they fix it until next time.

There is no innovation there. I guess some accountant has determined that paying sweat shop labour to untick an IP every time their brain dead system blocks the same sender with no spam history is cheaper than actually fixing their systems. This is a flashback to 1990s Microsoft where their software was buggy as hell and your support options were power cycling or reinstalling.

They not only put their company name on this mess but offer it on outlook.com which creates an association with the pro email solutions they sell to a massive enterprise market. They should be embarrassed.

oddmail was bought by yahoo

- Perl. This was at the time when the other languages available to me as a student were Java or C (mid to late 90s). Those were fine, but Perl definitely felt 10x more productive for me for the things I actually wanted to write. Plus CPAN was the first directory of libraries/modules that I'd encountered of its ilk.

- VMWare/virtualization. We used it for an Operating Systems class so we could learn by actually writing Linux kernel code and running it on a VM. This was huge at the time. Friends at other schools taking Operating Systems had to work on dumbed down simulations and "teaching" OSes. Before VMWare, if you wanted to work on the kernel, you had to have spare hardware and a lot of patience for re-building your system when you did something stupid. With VMWare, you could just restore from a good snapshot and try again.

- apt-get. Coming to Debian from (old, pre-yum) Redhat, being able to type a command and reliably install pretty much anything was a huge improvement over untangling RPM dependencies. Even RPMs were a pretty big improvement over manual compiling or Windows-style installer wizards.

- Numpy (or "Numeric" as it was called at the time). Vector math in clean Python that was mind-blowingly efficient. The only other option that really balanced performance and high level accessibility was MATLAB, but that wasn't suitable for using in an application.

I saw a joke the other day that went something like:

"What, is your grandma so senile that she can't type ./configure; make; make install" ?

Installing software on linux truly sucked before package managers.

Although UN-installing software was possibly even worse!

Ahh, reading the Makefile to find switches you need or don't; documentation, ain't nobody got time for README, yah I'll take the default switches; also moving where the binary will be installed, sometimes an obscure library will not be in the path, have to find it, oops, wrong version, upgrade lib, oops, breaks backward dependency of something else, revert, put new lib in different place, mod path, make clean ... First time I used yum, I thought, my God, my barbarian life!

Also, kernel patching roll-back! If you put in a kernel patch that broke stuff, go get the LiveCD and make some coffee and call your spouse, you gonna be there a while.

Network booting, that too. I mean, is network booting 10x local boot? I can't say, but you're not going to make a data center filled with tens of thousands of nodes if you can't network boot.

there are better tweets and memes floating around about how convoluted yield farming really is

For me, Python. I knew Perl was the "leet" language and was determined to add its power to my toolkit. I made several (three, I think) weeks-long intensive efforts to master it. Every time, I read the book, read PerlMonks every day, did exercises, and got to the point of writing useful scripts using pretty powerful features. I'd think "I've finally got it!" and would be a Perl programmer for a while, but eventually a few weeks would go by without any need to use Perl, and it would turn to mush in my mind, and I'd have to start over again at the beginning.

One day in 2000 I was yet again failing to do things in Perl that had felt easy six weeks ago, and I thought, "Huh, I think I remember how to do this in that language Python I fiddled with for a few minutes once after reading some blog post." I started typing Python and was very quickly able to get it working.

I didn't really want to write such easy, bland, straightforward code. I wanted to be a wizard who could do amazing things with a few cryptic characters. Writing Python was like doing a magic trick while simultaneously explaining exactly how the trick was done. It reduced my style points to zero. But I liked how easy it was, and Perl kept brutally showing me that I wasn't cut out to be a wizard.

Twenty years later, and Python is still an important part of my toolkit.

The "wizard" aspect was part of what eventually drove me away from Perl as well. I was never really into the whole JAPH/golf thing and I worked hard to write Perl that was well structured and readable, and there were plenty of other Perl programmers like me. But there was also always that part of the community that wanted things to be as obscure and obfuscated as possible and they were very visible. Python's complete rejection of that was really refreshing.

At first, it was just annoying DRM. But it was convenient.

- Before that, you had to manually update your games in order to play the latest version

- Without no-cd cracks, you were required to leave a CD / DVD in your drive

- with the addition of steam workshops, installing mods for certain games became easier. You didn't have to manually copy paste files.

- you have one central friend list, and invite system which many PC games use. It took some time until more companies launched own launchers and fragmented this ecosystem again.

- save game cloud backups became the norm. No need to manually backup a savegame folder if you want to ever reinstall a game.

- the refund system is user friendly (refund if you haven't played for more than 2 hours)

- steam link allows you to stream your games from a PC to other clients locally or through the internet

- steam remote play together allows you to stream a game to a friend for remote couch-coop. Other player doesn't need to own the game and since a recent update, doesn't require a Steam account.