The buzzword of 2021 was unmistakenly Web 3.0. Facebook, Instagram, Medium, TikTok, Twitter: Web 3.0 dominated the discourse. Investment funds were flocking to invest in any company loosely affiliated with the hottest new trend on the web. Depending on who you spoke to or what you read, Web 3 would kill Facebook, Twitter and every other popular website and application. In its place, Web 3 decentralised alternatives would take their place.
After an endless stream of betas and release candidates, Vue 3 is finally here. Congratulations to the Vue team and all of the contributors who made the release happen. As many of you know, I’m on the Aurelia core team and I’ve seen how hard it is shipping a new major release. Aurelia 2 itself has been in development for quite a while now. I haven’t made my criticisms of React a secret and I am glad that there are frameworks and libraries still around challenging React/keeping it honest, even if it is the king of the hill at present. In Vue 3, there are new composition features, support for TypeScript (finally) and other features which are more React-esque.
For such a long time, Firebase has been in a league of its own. Not only does Firebase offer hosting, cloud functions (AWS Lambda serverless style functions), but it also offers authentication, two different types of database and a plethora of other features. Honestly, nothing else has ever really come close to Firebase… Until now. Supabase is a promising open-source alternative that eventually aims to be a close replacement for Firebase. And if you’re thinking Supabase is some scrappy upstart, they were in the Y Combinator Summer 2020 batch and received $125,000 USD in seed funding from Y Combinator.
Depending on who you speak to, WebAssembly will kill Javascript, WebAssembly will enhance Javascript, and WebAssembly will merely appeal to a small subset of die-hard developers working on problems that require lower-level bare metal solutions written in a compiled language. A lot of work has gone into reducing the performance issues that have plagued WebAssembly regarding making JS calls (especially when working with the DOM). Efforts seem to be focused on making WebAssembly more than a memory-siloed thing, but rather a viable alternative for anyone wanting to work mainly within the confines of WebAssembly.
I’ve had this thought one and off over the last few years since I started using TypeScript back in 2015 actually. What if Web browsers natively supported TypeScript? If Web browsers could natively support TypeScript without needing a build step first, would it be possible and secondly, would it be performant? As in, you just build your site and instead of .js files you reference .ts files. It turns out, someone else had the same idea back in 2016 when they created an issue on the Chakra GitHub repository requesting native TypeScript support. The team had discussed the possibility but they were against it because TypeScript isn’t a web standard and they believe WebAssembly is a better option.
When I last tried Yarn v2, it was a nightmare. Besides the fact it was a completely new major version that fundamentally changed how Yarn worked (from its architecture to how dependencies were handled). After seeing news about the latest release for Yarn v2, I got to thinking and the idea I would migrate one of my Aurelia 2 Projects from Yarn v1 go Yarn v2 was born. This isn’t going to be a tutorial or how-to for upgrading. I didn’t actually encounter any issues upgrading to v2. In fact, this is quite a non-eventful post.
I recently built a new PC and did a clean Windows 10 install. As a result, I had to reinstall VSCode and everything else. I use PowerShell as my prefered shell in VSCode and encountered an error I sort of remember from when I did my last fresh install. The error in my case reads File C:\Users\dwayn\AppData\Roaming\npm\yarn.ps1 cannot be loaded because running scripts is disabled on this system. For more information, see about_Execution_Policies at https:/go.microsoft.com/fwlink/?LinkID=135170.
The Fetch API might seem new to some, but it’s already five years old with browsers rolling out support in 2015. It was a replacement for the dated XMLHttpRequest which was tedious to work with and a relic of the yesteryear of internet. Still, all of these years one feature that is available in XMLHttpRequest is the ability to handle file upload progress, missing from the Fetch specification and we are now in the year 2020, almost 2021 and still, there is no across the board way to handle file upload progress. This is the last missing piece before Fetch can truly replace XMLHttpRequest.
As some might be aware, there is currently a news war taking place in Australia. The Australian Government alongside the ACCC (Australian Competition and Consumer Commission) have drafted legislation which will compel companies like Google and social media platforms such as Facebook to pay for news on their respective apps and sites. Google recently weighed in on the issue with an open letter to Australians and now, Facebook has done the same issuing a straight-to-the-point press release about the legislation.
Google is well and truly on a roll lately. The Chrome 85 release is jam-packed with new features including the new content visibility property which I wrote about here. Something not many might realise is that Google has experimental support in Chrome 80 for Web Bundles. What are Web Bundles? Essentially, it is a new file format which allows resources in a web application to be compiled into a singular file. Think images, Javascript files, CSS and other resources you might find on a webpage. They can all be packaged into a singular file and work offline.