Serious question: as a user (not as a developer!), have you ever seen substantial improvement in a piece of a software from a ground-up rewrite?

In other words, have you ever used (but not co-developed) something where the developer(s) decided on stopping evolutionary work and instead embarked on a substantial rewrite, and the outcome as you saw it firsthand was a real improvement?

If so, please state your example. Please stick to personal experience, rather than hearsay. Thanks!

@xahteiwi fish shell comes to mind. Though, it's a bit complicated, because I didn't use it before the rust rewrite - the rust rewrite is what allowed me to use it in the first place.
@algernon @xahteiwi can second that, the speed and responsiveness after the rust replacements were worlds better.
@xahteiwi In UX, or UIs, often.
From a business logic or backend perspective, I wouldn't know. If the transition is done correctly, it should be invisible to me.

@andros "Often" is not an example; I asked (with a reason) for specific examples.

I also asked about improvements noticeable to users; if something is "invisible" it is not a noticeable improvement.

@xahteiwi For example, my bank's app. They improved the contrast, font size, and content hierarchy; they eliminated recurring modals in favor of dynamic structures (new steps or dropdown menus), added more contextual buttons, and made the help chat always visible.
Another example is WhatsApp; the navigation bar was moved to the bottom on Android, resembling iOS. Minor, but it improved accessibility.
Another case that comes to mind is the Renfe website (the Spanish state-owned train company). There was a huge amount of work involved in updating part of the backend, including the user experience. All of this was done without affecting users.
@andros How do you know your bank app's UX improvements (or WhatsApp's) were the result of ground-up major rewrite?
@xahteiwi Redesigning an app or website isn't just about code. There are other tools and technologies involved. I don't know about the code itself (I have no proof, but it doesn't seem that far-fetched), but the most plausible scenario is that the UX designer had to create new prototypes, the project owner had to define new workflows, and the graphic designer had to create new files.
@xahteiwi yes, icomoon.io v1 and v2 apps. The v2 app is completely different so, I assume, a rewrite. It has multicolor font support and better UX.
@xahteiwi @carlton Django “magic removal” and newforms were both rewrites (and complete API redesigns) in the 2006-7 timeframe; both were wholesale replacements of older ORM and forms layers, respectively. Both immeasurably improved the user experience. (Admittedly, the “users” in that sense were Django users, who were developers - just not developers *of Django*; I *was* on the Django core team at the time, but I was also a user. Not sure if that meets your original criteria)
@freakboy3742 That does qualify, thanks!
@freakboy3742 @xahteiwi I think Django migrations might also count, replacing South. The main difference here is that South was a different package to Django, but they both had the same primary author.
@xahteiwi Maybe Winamp back in the day, not sure it was a ground up re-write though. A lot of software going from DOS -> Windows would have counted in a way I suppose. But yeah, I think you've got a point :)

@xahteiwi Element X comes to mind. Element decided to put its legacy clients on life support, then developed a proper Rust SDK to share some code between its iOS, Android and web apps. It rewrote its mobile clients.

On iOS at least, the difference is spectacular for me.

They’re also in the process of refactoring Element Web to progressively port various elements to a better foundation, which doesn’t stop the development of new features.

@thibaultamartin @xahteiwi funny enough element for me is a counter example. So many features got lost by that rewrite. Also non synapse servers lack compatibility for things like registration since element x has no support for the old API and so on. It for me was enough to not use any element software outside of being told at work
@xahteiwi Does it count when a new company creates a much better version? For example, modern banking apps like Monzo and Starling compared to legacy banking.
@lilyf No, that's not what I'm after. You can't conceivably call that a rewrite.

@xahteiwi
In Python development, tox comes to mind. If you're not familiar, it's a script runner and environment manager -- it can install your project under multiple Python versions and run your tests.

I'm a user, not a maintainer.

Development fully stopped on version 3. Version 4 has a better CLI and I've seen new features ship faster since the full rewrite. Very quickly, v4 became noticeably better than v3.

@sirosen Good point. I do use tox (daily, indeed), and I had forgotten that the version 3→4 transition was a big rewrite.

@xahteiwi Blender big jump from 2.4x series to 2.5x series.
It took a long time (it was an huge task) to get feature parity, up to 2.6x series.
But the first 2.5x where already a big improvement and almost daily usable after the first ones.

A small but significant one was done afterwards in specific (but big) parts of the tool in the next 10 years.

@xahteiwi
Well, since people seem oblivious: Netscape 6 (and its continuation, Mozilla) was infinitely better than Netscape 4, when it was finally out. Of note, a rewrite of probably comparable magnitude - the breaking of the Suite to produce Firefox (yeah, some names nobody remembers in the middle) - did not give immediate returns, but I do believe it contributed to the project's longevity.

@xahteiwi BIND (name server, DNS server) comes to mind.

Then Python. Version 3 being much better than some early version (don't remember which one exactly) I encountered for the first time.

Let's Encrypt (certbot). Modern versions are much better than early client available only as a source code from Git.

MEW (MyEtherWallet). Mobile app much more friendlier than early Web app.

@xahteiwi
The QLC+ frontend rewrite (4 to 5) seems to be headed to a good direction, but has not reached feature parity yet.
@xahteiwi
The details are confidential, but i have had 3 (large) converisons conversion projects over my career and the reactions are as followed:
1: "finally we do not have to click through 8 menus to finish"
2: "wow,it does not take 50 seconds to load, but <2" (real measurement)
3: without the conversion, we could no% have processed those documents at all (sheer complexity of the data has grown over time, almost impossiblento calculate by hand anymore)
@xahteiwi this one is still ongoing, and there are a lot of pain points, but for my specific use cases, VLC v3 beta is far better for using a media library as an actual music library (although now it seems worse at opening arbitrary files, so again, better for my specific use case).

@xahteiwi At previous job, my colleague rewrote an internal tool from scratch. New one was pretty much on par features wise, it did not improve stability … I do not have data to compare but felt the same in numbers of crashes but ran in less than 15s versus over 3 minutes for the legacy one. Made the crashes much more acceptable :)

Could he have done it by rewriting the offending bit? Maybe but he was adamant this was too tangled to be practical.

@xahteiwi Apple switching to OS X from original classic Mac OS. It was a bumpy transition, but the benefits clearly outweigh the losses and the 'golden age’ of OS X was pretty great. (I do miss the old look and feels.)

Apple’s switch to PowerPC, Intel and then Apple Silicon is another, there is substantial re-engineering going on under the hood to make it appear seamless to the users and serious performance and efficiency gains.

Microsoft’s leap from Window 3.1 to XP is also a great example.

@xahteiwi

Though a bit niche as they were internally-used applications:

• a rewrite of a DOS utility to support Windows (this was Win2k era). A first rewrite happened and failed catastrophically since y'know, it helps to actually talk to the users. So a *second* rewrite happened (shifted to a different project-manager and actually involving users in decisions) and we got regular praise on how much better it was than either the DOS version or the half-baked Windows version

• software that ran on ruggedized DOS handheld computers was completely rewritten to run on ruggedized PocketPC PDAs. The new code made it easier to add features that were pretty much impossible to add to the old code-base, and users greatly preferred the ease-of-use (as born out by sales figures since both were offered/sold concurrently).

• several ETL tools at $DAYJOB where first iterations worked but had geeky command-line usage. So they were rewritten from the ground up, making it easier for the non-geek users to just click some buttons rather than copy/paste command-line invocations.

I wish we could do a complete rewrite on some of our in-house apps because they're split across two databases and have a LOT of normalization issues. We (in-house users and customers) bump into weird limitations all the time and a lot of processes/code is duplicated between the two stacks. But 20yrs of code/data is a lot to surrender.

@xahteiwi Netscape to Firefox comes to mind
@chrisjrn @xahteiwi that was my first thought too
@xahteiwi the online editor editor behind the Fietsersbond Routeplanner. It was long overdue changed from java and came out with both better UX and more stable.
@xahteiwi 1996 blender against ... I would say 1998 or 2000 blender, 100% rewritten. Back then, Blender first versions were a very bad joke.

@xahteiwi

I used a file indexing tool on Macs in the 1990s. It could look inside my sit and cpt files
and then I could search by a filename and know what floppy to pull out. (Of course I named all my disks uniquely.) It crashed however if you pulled up index number 65536 on the screen. More than a screenful away from that, fine, just ±30 or so was at risk.

The complete rewrite fixed that, but made it less useful in other ways I can't recall. Anyway, put that down as a mixed result

@xahteiwi
Isn't that basically the entire Linux kernel every couple years for the last 30 years?
@xahteiwi ownCloud PHP -> OCIS -> @OpenCloud is now written in Go.
@xahteiwi does Ceph OSD FileStore to BlueStore count?
@gurubert Well, yes it certainly counts, but in the grand scheme of things it was compensation for two prior rewrites: EBOFS being replaced with a rewrite that heavily relied on then-unstable features of btrfs, being replaced with rewrite that had to deal with the shortcomings of XFS.
@xahteiwi Evince to Gnome Papers (where Papers is/was a fork of Evince). As they now also have rust in their codebase, I am pretty sure it is a rewrite. And a lot better from the user perspective.
@der_mit_ph I might give that a try when it's included in an Ubuntu LTS (should be in Resolute, a couple of months from now).
@xahteiwi The rewrite of the dependency solver in the SuSE package manager, ultimately yielding zypper. What took minutes suddenly was done interactively.

@xahteiwi YaST2 was a vast improvement over YaST.

All other examples I can recall were more than "just" rewrites by the same entity: more like clones or "new product based on lessons learnt".

Does drbd9 count, for example?

@larsmb Hard pass on that question. 😀

@xahteiwi I meant for the qualifications.

In the end, I'd argue it definitely made things better.

@xahteiwi - IBM OS/2 2.0 in … 1992/93?
- Siemens Simatic going from S5 DOS / character based to S7 and GUI ~1996 and then to TiA ~2014

@xahteiwi
I'd add neovim to the list. Lua as a scripting language opened a way for much bigger plugin ecosystem.

Not sure if this counts.