Matisyahu's Blog

WebAssembly Garbage Collection is being worked on for Safari (link) as they make changes bit by bit. It’ll be interesting to see how Webextensions in the future will make use of WebAssembly Garbage Collection not to mention the increase in complexity of web based applications requiring a sophisticated framework so that a great experience can be provided to end users. As much as I loath the increasing prominence of web apps, the reality is that the industry is moving to more cloud based web apps or if theylocal applications the move to using web based technologies allow them to target multiple platforms and form factors without having to write bespoke implementations with hard coded UI for specific screen sizes etc.

Google is integrating Google and Messages together (link) where in the long term it’ll mean the ability to setup a public profile for RCS to RCS which will make for a much more feature rich messaging experience. I don’t think that we’ll see a merging of Google Chat and Google Messages because they’re designed to achieve different goals. With Google Chat the focus is chatting within the Google ecosystem where as with RCS any sort of development needs to be done in consultation with mobile carriers, telecommunication software and hardware vendors so that support can be added etc.

It’ll be interesting to see whether Google is succesful in lobbying the European Union in terms of getting iMessage classified as a gatekeeper and thus subjected to the interoperability requirements (link). Personally I’d like to see iMessage and RCS interoperable so that we don’t have entrenched market domiance simply by virtue of the lack of interoperability. Btw, this isn’t something new given that anticompetitive legislation requires those businesses that are in a dominant position ensure interoperability so that competition can thrive by new players coming into the space and being able to interoperate – a good example of that was regarding the European Union and Microsoft many years ago regarding protocols, file formats and file system support.

Apple released a refresh of their Apple Silicon in the form of the M3 which is based on the ARMv8.6-A ISA but there are rumours that there is an architectural change that probably lines up with the move to ARMv9 so that’ll be interesting to see whether that translates to big improvements in performance and power per watt. In the Intel world the chiplet design is coming to their mobile processesors because they’re in the most need of the benefits that come with it but I’d say eventually with thei Arrow Lake and Arrow Lake refresh that we’ll see desktop processors adopt the new chiplet design.

One of the major factors that cannot be overlooked when it comes to the overall experience is the operating system itself and whether the frameworks are optimised. I’m looking at the Windows 11 Canary Channel notes on the Windows Insider blog and it is interesting to see how Microsoft is slowly replacing Windows components piece by piece and replacing them with reusing the same backend code but replacing the front end with modern Windows App SDK frameworks particularly when it comes to WinUI. There is an article here (link), it makes sense to reuse known good code that has gone through years of debugging and optimising then replacing the UI with WinUI vs. what they tried to do in the past which were complete rewrites only to find that what sounds great on the whiteboard can be entirely different when it is put into action.

I wouldn’t be surprised if what we end up seeing is jettisoning UWP in favour of going back to a win32 backend, replacing the UI, keep the back end code, and modernise where possible. Long story short, doing what they should have done right from the outset. It reminds me of Joel on Software regarding never rewrite software (link). There is a time and a place to throw out old code but I’d argue you have to have a really good reason to do so, ‘just because’ isn’t a good enough reason just as a business should avoid bespoke solutions in favour of taking an office the shelf product then customise it via the provided SDK. There was a great post made over on Hacker News:

I’m a big fan of Joel Spolsky’s earlier blog posts, but to be honest, I don’t think this piece has aged well. If anything, I’m more of the opinion now that you should almost always plan to do a rewrite, eventually. Lots of big companies successfully rewrite stuff all the time. Google is fairly well known for having rewritten large, critical pieces of their codebase over the years.

If anything, what should be warned against is big bangs. Netscape’s problem isn’t that they did a rewrite (which eventually became Firefox, mind you) it’s that they essentially abandoned their old code too early, and similarly, they also announced the rewrite too soon.

If you’re going to do a rewrite, do it quietly, and don’t announce it until it’s close to ready, and even then you can roll out slowly. For example, the infamous Digg v4 debacle is another example, but the problem isn’t that they did a rewrite, it’s that they did a rewrite to produce a product nobody wanted, and they burned any possibility of going back after they released it.

https://news.ycombinator.com/item?id=23726062

That being said, the better solution to a total rewrite is to treat programming like the existentialist idea of ‘being in a constant state of becoming’, that there is no end point but rather a constant cycle of refinement, refactoring, more refinement and more refactoring, that there is no end point but rather a continuous and on going cycle. If it is a continuous cycle then it avoids having to do big rewrites because instead you’re always moving it forward vs. allowing code to stagnate resulting in the process of refinement and more refactoring more difficult. Long story short, it is easier to keep something moving than stopping then years later trying to start it back up again.