What's New in Flynt v2.0

Our WordPress Starter Theme got its biggest upgrade. Flynt v2 makes developing lightning fast websites fun and provides editors with a smooth experience. Learn all about the most significant improvements from the core team members.

Highlights
00:00 Introduction
00:34 Key improvements
01:11 1) Performance: JavaScript Islands
04:07 2) Editor Experience: Gutenberg and ACF
05:30 3) Developer Experience: Vanilla JS and CSS Variables
12:12 Feedback

Links
- Flynt Website: https://flyntwp.com/
- Flynt PageSpeed Test Results: https://pagespeed.web.dev/analysis?url=https%3A%2F%2Fflyntwp.com%2F
- Flynt Release Blog Post: https://flyntwp.com/flynt-2-0-rekindling-your-love-for-wordpress-again/
- Flynt GitHub Discussions: https://github.com/flyntwp/flynt/discussions

Steffen: 0:00

Hey Dominik, we've got some news.

Dominik: 0:04

Yes, that's right. We released flint 2.0, right, a big version update. How long was it to get it done, Steffen?

Steffen: 0:14

Oh, it's been years, like literally, I think. We started working on flint version 2.0 in 20, end of 2020. I think kind of like that's when we, I think, released the previous version latest one, and then we started working on it and we went through a couple of iterations. Finally, we ended up with a couple of key topics that we wanted to focus on on this release, and these are performance, editor experience and developer experience. So let's talk about the main features here and advancements in performance. I think the most noteworthy thing to highlight is that we're getting a full 100 out of 100 in the page speed test results, which I think is very amazing, and we even included a button to test it yourself on the website. So just click that and you will be able to verify yourself if that's actually true. And what did have the biggest impact on achieving this in the performance, dominic.

Dominik: 1:17

Yeah, so the biggest impact was actually getting down the JavaScript bundle size right. This is pretty tricky to do, but there have been a lot of like developments and like in the JavaScript ecosystem and so on, and focusing on especially on JavaScript boot uptime or start time has led to a concept of like partial hydration or islands, which we implemented with the custom element that we use to initialize or instantiate like all of the JavaScript that is needed on a page. And we have like some hints there, like usually by default we load all the JavaScript on like only if a component is visible in the viewport, right. But you can have like client hints to say you want to load it on idle. That means like when the page has loaded and the JavaScript is not blocking the main thread, then we have the on load. Actually this is the default because we didn't want to change anything to the existing behavior.

Dominik: 2:16

But mostly all of our components that we code ourselves use the load on visible attribute or directive, and load on load just means load immediately when the page loads, right.

Dominik: 2:27

And then we have like another attribute which is load on media. That means you can selectively tell it to load a script file only when a certain media query is met, right. This actually means so we break up our main bundle into smaller pieces, like for each individual component, where we separate JavaScript file that is only loaded when this condition inside of the wrapper element, like this flint component, is met. Like. This can be used for anything mainly, and this has led to dramatic JavaScript performance improvements, and the nice thing is also that it scales really well, right. It doesn't really matter how many components you have on a page if you only load those that are in the viewport, right, and there are never that many components that you load where you have, like, the unload directive, because this is usually only for, like, maybe, tracking scripts or the menu or things like that that really need to load, no matter where you are on a page.

Steffen: 3:30

Yeah, right, and so this actually happens, for example, with a slider. Like when you have a slider component on your page, then the JavaScript only loads and initializes once you scroll it into viewport. But it happens so quickly that it's actually seamless, like you shouldn't be able to notice that this is happening and this is really great, right? This really speeds up the whole loading time and the experience so much. So I really love that and I think that's a great concept, and I also like the implementation that you came up with. So I think that's it about performance, the most noteworthy thing.

Steffen: 4:07

Then let's talk about editor experience. One thing that we did, also in terms of editor experience, is we finally added support for Gutenberg. So, specifically for WordPress posts, you will now by default have the Gutenberg blog editor. We think this is the great experience, especially for editing long copy. What we also did is we automatically integrated editor style, so these will be generated from the base style that you create with Flint and it will just look like the real thing in the front end. You can use all kinds of blocks by default, and you can also, of course, make a more narrow selection of blocks that you want to support, but these aren't Flint or ACF blocks, it's just like default Gutenberg out of the box.

Steffen: 4:56

When it comes to editing regular lay outed pages, we still stick to the ACF flexible content field, and there you will have a new feature as well the search feature for the component selection. So there I can now search for image and it will show me all the image components that I have, making it quicker and easier to drag and drop new components into a page layout. That's it about the editor experience. Dominik, would you like to talk more about the developer experience enhancements?

Dominik: 5:31

OK. So yeah, we've put a lot of thought into development or developer experience, and also try to get the follow the latest trends in the JavaScript world. While we haven't switched to TypeScript which usually everyone does nowadays when they develop a new project we have at least gotten rid of jQuery. So that's a big thing. We have not only gotten rid of jQuery, we've also gotten rid of our standard approach on how to write components JavaScript component scripts where we always had custom elements for each component. Now we are only we have a wrapper custom element for these partial loading, for these islands, but a component itself is just a JavaScript function. We export a default function and in there we have some helpers to help you do stuff that you need in the front end, and while before you had a lot of boilerplate that you had to write, always like defining a new custom element, registering it in the custom element registry. Also, we before we needed to have a polyfill for the built in custom elements in Safari. Now we don't need that anymore, and so this has gotten a lot slicker, or slimmer, let's say so. For example, here we have the slider images component that comes with the free version of lint, and you can see we are only exporting a default function that takes an element as an argument, right? So that is the element kind of as it was before, with like what's upgraded as like a custom element. Now we just have a DOM element here, so we have something to scope all of our JavaScript to, kind of right.

Dominik: 7:12

Then we have these helper functions, with helper functions for building reps and for getting the JSON. Building reps is like a thing where we kind of lazily have a, an accessor for DOM attributes, right? So in the tweak or template file you can say here let's see data minus ref and then give it a name, right. So data ref prep and data ref next. And then when you say build refs in the function here, it will create an object that once you access the refs dot prep or ref dot next, it gets the element from the DOM. So there's no like as we did before with jQuery, like parsing of the entire element at the beginning, but it only like searches this element once you access it, right? So here you have like these calls to ref dot next and ref dot prep.

Dominik: 8:09

Then getting the JSON was also something that we do quite often. We have a script tag of type application JSON in the component and that's where all of the data for the component lives that we pass from the server, right? So again, if we look at the index tweak here at the top we have the JSON data that comes from our PHP render and component data filter. And, yeah, this way you can easily access that with a helper from and here, and then we initialize the slider that's just like some swiper code and we have a. The returned function from this default function is a cleanup function, right? So whenever this element gets taken out of the DOM or a destroyed, we will call this function that you pass in here, so in this case, whenever this element gets removed, we call swiper destroy for cleaning up, Like.

Dominik: 9:07

This is useful for like, if you set intervals or timeouts or things like that or bind events to DOM elements, then you can just call that whenever you need the cleanup. Yeah, so this is a bit about the component structure, and then one one other part is the theme JSON, where we have integrated, so we disable, basically most of the functionality for setting colors, for doing or manipulating the layout and so on. But, and then we add our custom properties that we define in our base style sheet here for the content size and the white size, for example, and also we use our flow spacing property for the block gap, the padding, like our container spacing for the padding, and this can be extended. This probably will be extended in the future and this is just to give you a head start and to have the most basic things covered. And we are also using VIT instead of Webpack for our bundling and this has drastically reduced the configuration that is needed. So it's like really a simple, simple configuration file that most people should understand that that have touched VIT before. We have our own little plugin that does like some loading of the assets, and we also had to rewrite a little bit how assets gets load get loaded Because in VIT you don't write the assets in Dev mode to the disk anymore, but they are just in memory and are served by a external web server. But still, like this has increased the boot up time, the build time, the hot reload time and so on, so this is really really nice for most developers.

Dominik: 10:52

With that, we also dropped IE 11 support, while it is still possible to do that with like a legacy plugin for VIT and making like a few minor changes.

Dominik: 11:02

Yeah, we have dropped it for our code bases, and one of the main reasons why we did that was also like the CSS custom properties right, because custom properties are not and like there is so much like CSS stuff and so many concepts that are not supported by IE anymore and the usage has gone down a lot. So, and to give you an impression on what these custom properties look like, so we still use as CSS and we still, in some cases, use as CSS variables. So for most colors and like other things, we have now real custom properties in CSS that you can also modify at at runtime, kind of like in the browser you can see that and here you see that we mix these SAS variables and the custom properties. But all in all we have now a much leaner and more modern code base in CSS, in JavaScript, and, yeah, the PHP side didn't change so much, I think. But other than that there have been lots of improvements that will make your daily life just a bit more modern, a bit easier.

Steffen: 12:11

Yeah, right, I think that's it. What's new about Flint version 2.0. If you do have any questions, please go to the GitHub discussions and open a new topic there and let us know if you have any feedback, check it out and we hope hope you will have a great experience with the new Flint version and I'm looking forward to your feedback and contributions.

Siegfried, deploy!

What's New in Flynt v2.0

Listen to this podcast on