Lightningjs 3: (almost) a year later
Can you believe it’s been almost a year since Lightningjs version 3 saw the light of day? Back in September 2023, at the RDK Global Summit, we got the chance to witness Lightning 3 and immediately start playing with it. Since then, a lot has happened. Just a few days ago, we saw the first full version 1 release of both Lightning and Blits. A fully production-grade release! And, now that the Global Summit is planned (September 17th) yet again with hopefully some more cool announcements, I thought now would be a great time to have a look and see what has changed since we first laid eyes on Lightning 3.
The statistics & community
Looking purely at statistics, Lightning 3 has seen plenty of activity in the past year. As you might know, with the new version the code is split up into different repo’s. Integration repo’s that most developers will build apps with, and the renderer which stands at the core of how Lightning functions. All of those have seen plenty of movement:
- https://github.com/lightning-js/renderer: 500+ commits, 33 releases
- https://github.com/lightning-js/blits: 650+ commits, 39 releases
- https://github.com/lightning-js/solid: 300+ commits, 8 releases
What’s cool to see though, is that the community has really picked up on Lightning 3 too. With Lightning 2 already being the go-to for many out there, it was a logical consequence of course, but nevertheless really awesome to witness first-hand. Besides the community actively contributing in some of those commits, what’s really cool to see are the lively discussions and support on Discord. Many are dipping their toes in development with either Blits or Solid, and receiving help from not just the Lightning team but others as well.
If you’re looking to get started with Lightning development as well, you could follow along with the Blits-specific intro via this link. And for any questions, you can join the Discord and directly get support from the community here.
Focus on Blits
Back when Lightning 3 launched, and as you can see from the repo’s mentioned above too, there were two application frameworks with full support: Solid and Blits. Arguably one of the biggest changes since then, is the fact that the team has decided to put their focus solely on Blits for the time being. To be completely blunt, I was a bit surprised by the duplicate focus to begin with — given that Lightning 2 also only came with a single way of doing development.
What’s cool though, is that Solid does continue with widespread community support. In this case, the project moved over to a new repository and is still being worked on. In that same trend, I’ve seen many other frameworks also actively being worked on. React and React Native, Vue, Svelte; with the renderer being open, anyone can tie their framework of choice to Lightning now. Albeit not all are being developed in the open, it’s still a very cool development to witness.
Blits is better now
When it was first introduced, you could clearly see that Blits was still a bit barebones. It came with support for ‘Elements’ and ‘Text’ tags, with some default configuration options and routing functionality but that was about it. Those tags are to this day still the base of what Blits entails, but a lot has been added around in order to make development a lot easier.
Loaded and error events
Being able to react to what’s happening with your UI is crucial if you want to give your users the best experience. That’s why not even a week after the initial launch, two new events were made available for Element and Text nodes: @loaded and @error. These events get triggered, as you might expect, when an element or text gets loaded or results in an error. This can be particularly useful with images and ensuring they are displayed correctly; as well as handling dynamic sizes of your text or element.
is-directive
Arguably one of the most powerful additions. The ‘is’-directive allows you to dynamically define the type of component that’s being used for a certain element. Imagine you have a swimlane or row component that’s used to display different types of cards. You might have a landscape card in one swimlane, while the second has a portrait. Using the new :is functionality allows you to define that very easily, making your swimlane completely reusable:
// Swimlane.js
template: `
<Element :for="(item, index) in $items">
<Component is="$component"></Component>
</Element
`,
props: ['items', 'component'],
// Page.js
template: `
<Element>
<Swimlane :items="$row[0].items" component="$PortraitCard" />
<Swimlane :items="$row[1].items" component="$LandscapeCard />
</Element>
`,
Pre-compilation
Initially announced with the Lightning 3 announcement at the previous RDK Global Summit, pre-compilation wasn’t yet available at launch. At the beginning of 2024 however, pre-compilation was finally added. With Lightning being all about performance, having certain steps happen at runtime will obviously not help. Now that certain compilation steps happen at build time, we can squeeze some extra speed and performance out of the applications. In order to enable the pre-compilation, you will need to configure some steps in your vite-build process. This, and some additional information on pre-compilation, is available in this blog from the Lightning team.
And more
Highlighting and cramming every single change inside this blog was obviously never going to work. A lot has still happened however that is incredibly useful or improves the way we work with Blits. I’d recommend looking at the nicely-kept changelog for every release version for a bigger overview. You can find useful updates to the router, a ton of bugfixes, improvements to MSDF font usage, and more.
At the core — the renderer
Version 1.0 has just been released! When Lightning 3 was introduced, it was very clearly put out in an alpha or beta stage — very early days with a lot of improvements and changes still coming. Now, almost a year later, the first 1.0 release has literally just dropped. A great sign for anyone looking to adopt Lightning on some way, shape or form. So what has changed since the first version?
Support for older devices
As with any big framework update (in this case even a full restart from scratch), the amount of devices supported is likely to decrease. With us being in the TV-world, that does have a much bigger impact than for say someone working solely with normal web-browsers. Luckily, some updates to the renderer have made support for older devices possible after all. For example, due to the previous hard requirement of the ‘OffscreenCanvas’, prevented usage on devices with older than Chrome 69 (meaning even LG WebOS 2020 wasn’t supported). It shows the commitment of the team to get as big a support range as possible, even if their primary focus is on newer STBs and TVs from those in the RDK-community.
Optimisations and improvements
At it’s core, the first release of Lightning 3’s renderer had support for most of the functionality needed to create an application. So it’s no surprise that the majority of focus since then has been on improvements and optimisations.
One of the most recent changes that has particularly seen an impact, is the change to remove the multithreading support. While multithreading is something that’s likely to make its way back into Lightning, at this moment most devices don’t actually have proper support for the functionality. Besides that, the used implementation had some caveats that resulted in increased memory usage. And while the removal does decrease the performance in certain cases (e.g. when updating many rows), in most of the other cases the performance and memory usage has improved. You can find the exact performance and memory changes in the pull request on Github.
Canvas2D rendering
In the same trend as the support for older devices, a rather large component of that is the way the renderer works. Where most of the newer devices have support for the default renderer using WebGL, not all devices can support this. And even if they can, the performance with Canvas2D might even be better on certain TVs. At the inception of Lightning 3, Canvas2D wasn’t available, contrary to its predecessor Lightning 2 (which does support it out of the box). Well, now Lightning 3 does too! With a rather big change, you can now configure using Canvas2D or WebGL. Especially for those using Lightning 2 in production today, this is a very welcome change.
What the future holds
With the just dropped release of version 1 of the renderer and Blits, we are likely to see an influx in usage of Lightning 3 applications making their way to production. The result of that will be a lot of feedback from end users, resulting in a lot of potential work to be done on not just the renderer but also Blits, Solid, and any other potential frameworks built on top of the renderer. It’ll be very interesting to see what changes will come out of the usage in production.
Next to the production usage, I’m also expecting to see some interesting updates from the RDK Global Summit being held in September. At the same place where Lightning 3 was first presented last year, this year will likely see some cool announcements as well. Time will tell.
