This is a transcript. For the video, see Has application development become complex? A discussion with Fabian Franz.
Michael Meyers: [00:00:00] Hello, and welcome to another Tag1 Team Talk episode, the podcast and blog of Tag1 Consulting. Today, we're going to be talking to, and walking through some code examples with Fabian Franz, the VP of software engineering at Tag1, about how to reduce the complexity of your applications by using Preact and HTM.
I'm Michael Meyers, the managing director of Tag1 Consulting. And this talk is going to be broken up into two parts. This is part one we're gonna be talking about why application development has gotten so complex. You know, there are many great reasons for it, but it isn't always necessary. And in part two, we're going to be talking specifically about reducing complexity and making your development a little easier with Preact and HTM.
Fabian. Welcome love having you, appreciate you giving us a walk through today.
Fabian Franz: Yeah. Glad to be back.
Michael Meyers: Oh, you know what, let's start with the broad overview, you know, why has development gotten so complex? You know, what are you referring to when you say [00:01:00] that? Can, you know, can you give me some examples of, of how it's gotten complicated?
Fabian Franz: So, one thing that I've seen many, many people add to things is tooling. And don't get me wrong. Tooling is great. We have things from engineering dependencies like Composer, we have things for managing dependencies in the JavaScript world like NPM or yarn. But as you can see, there's already two managers for that.
So maybe it's a little bit complex tooling. And then when you build a JavaScript application, especially in the front end, but then you have to deal with this Webpack and, or, other technologies, bundlers, purviews, Yan watch, like for example, you want to just do things, change some things, and then you have to always have a watch process running that is persistently checking your files and checking if there's any updates and it rebuilds the JavaScript application.
If you talk about the front end world more in [00:02:00] terms of CSS and they have been SASS, LESS, SMACSS, et cetera, and all of those, who will also have a process running persistently that is watching all the time has anything changed and then rebuilt the things.
Often as a nice side effect it also shows your live preview, like your app is nicely hot, reloading changing, so there's advantages to that as well. But all of that tooling led to the, On Twitter, I've seen that there was someone was like, yeah, we're getting into JavaScript nowadays. You need a PhD.
And, this was one of the parts. On the PHP world, on the other hand, For example, some examples are composer where you are building a, you are not having your application. Like, traditionally you have your PHP application, you add your modules, you push it to the server and then. It's deployed, but besides that you add an additional build step.
So another build step, like, you have a CI/CD [00:03:00] system which installs everything from Composer, then it builds to application essentially, and then it deploys it to the server. Maybe also built to a CSS, maybe built for JavaScript at the same time, et cetera like that. And, for me, that was a surprise.
I know just these trends are there. But I personally didn't really like them as much. And the reason is that I came originally from a C, C++ background, being a professional C, C++ programmer, long-term open source contributor to various things. From Linux kernel modules over, patches over just hacking things a little bit there of our various open source projects written in C, and you know what, in the C world and also Windows programs and et cetera, you always have this thing called the Build. To the extent that Joel on Software once said, if you have like, a nice program, you need to have a one-step build. So, you have need to be [00:04:00] able to deploy your application always just with one step. If you need more steps, if there's more complexity, then what do you do at night? Suddenly if you need to deploy a hotfix for some application or whatever, if you cannot build it before, reading 20 pages of documentation.
So, like that. And while for a compiled application, a build step is absolutely necessary, we cannot not have it for very obvious reasons. I never understood why people are adding all this complexity to something which is essentially zero step build. And also one of the largest strengths of Drupal!
You have a Drupal site on the internet, you click on modules, you enable a module and it's enabled. There's nothing like rebuilding your site because there's a new module now. Drupal all does this dynamically. There might be something happening under the hood. That's fine, but there's no additional step for you to [00:05:00] do.
So that's what I call simplicity. And again, the simplicity of the first PHP, JavaScript CSS pages has been, you've written some little PHP. You upload it to some server. You reload to your page and there. You change something, reload your page, your change there, and same as JavaScript. You change something, your change is there. Same as CSS.
So we had a time where we didn't need all this tooling and we had been being perfectly fine. And, as has had this tooling, it's a lot of complexity. And, this is something that, I think we can do better because complexity introduces, people need to learn new things and they can obviously learn, but onboarding can get sometimes a little bit slower.
And what if your tooling has a bug.? What if MPM is down? What if the Composer libraries who are depending on for your build are down, [00:06:00] then you might have a real problem. And, that's why, we, at least for some clients at Tag1 have developed a philosophy, in combination with the client also wanting this, of no builds.
And, that's why I want to talk a little bit more today, but you probably have some more questions.
Michael Meyers: I have a lot of questions. Before we get into the simplicity side of things. You know, you mentioned, you know, hot previews, like why, like what led to this complexity? Was it, you know, just people getting, you know, out of control or, you know, the there's, there's clear reasons why people are using these tools.
Is it things like it's adding performance and scalability, you know, what, what are the benefits of this tooling?
Fabian Franz: So, Now we have to distinguish several cases here of what tooling we talk about. For example, if you talk about SASS or LESS, which are CSS pre-processors, then it's pretty clear that just by using SASS or LESS as a pre-processor, you need this build step; because you've write your [00:07:00] Sass.
Like, for example, if you have some very complex select or change, and then you can just nest it, but CSS is getting a lot of that natively. So, that's the other part, I think historically many, many, many of those tools have not only been written because people just love writing tooling.
Everyone wants to write a package, man in their lifetime. And a bit, because there was a necessity for it, because if you go back 10 years or five years, the browser world wasn't there where CSS could do a lot of what it can do now. There were no CSS variables. Not at all or at least there were, but then there was Internet Explorer 11, which is now finally deprecated, which you still had to support, or it was support in Chrome, but it was not supported on Safari on some obscure, a older version, or it was supported in Safari [00:08:00] perfectly, but then Firefox had a bug so that you couldn't use this new functionality all the time, because then you would break Firefox, et cetera like that.
So, yeah, web developers, especially in the front end world have had a pretty rough time. I would say over the last years, and we are in what I would call a golden age by now where browsers and that's what we will be using later in the next next part. Browsers are now having JavaScript modules, which allow a lot of that would be showing.
They, CSS has become so powerful as the CSS variables and certain other things that have been added to the spec. Like Flexbox. Imagine, we used to style with floats and, and, sometimes even back to tables, if the layout was too complex and in the very, very old days of Netscape 2.0, we started everything with tables.
Fabian Franz: So, I'm just saying this new things, like Flexbox, CSS grid, CSS variables [00:09:00] that just make, things that joy. But before you had to use Sass or LESS. If you wanted things like CSS variables or you need to write very disciplined handwritten CSS code, which is a lot of what we had done, then in the end, it works and for not too complex layout.
Still a great choice because when I learned CSS, even when the web wasn't as great as it's now, but, Sass and LESS obviously also have some advantages. I'm just saying, as we are approaching, in my opinion, a golden age, those tooling becomes less necessary in that, or at least this explicit build step in that.
Michael Meyers: Before we dive into like, you know, some of your explicit solutions, which we're going to do in the next part, just conceptually, you know, how are you suggesting that we reduce this complexity, you know? And, and is that a parallel to, are you, are you saying hearkening back to the old days?
Like, you know, we're going to do, we're not doing things in [00:10:00] tables. But, what is your general approach to getting rid of these build steps and, you know, these tools that aren't really necessary anymore? You know, what are you advocating for?
Fabian Franz: Yeah, on some of the sites I've been working for over seven years now.
And how have we avoided these build steps is, we never allowed those tools, in the first place. So, another point is if you're writing a headless JavaScript application for example or a real application, like a front end, like something, which just tracking times or tracking to dos or something like that.
And everything is JavaScript based. You definitely want some tooling for that. That's - that's for sure. It's just for our more traditional Drupal based websites, that, I'm saying, and you sprinkle some, react widgets here. And there was some, some JavaScript, some interactivity that you need. That I'm not really seeing way we need all this complexity in that.
And you are right. For example, a build [00:11:00] step can reduce, for example, the size of the JavaScript itself. Like it can be minified, it can be optimized in that. However, Drupal is still, unless you deactivate it. But as soon as you use certain functionality Drupal is still using jQuery, which is like 200 kilobytes and 40 kilobytes, gzipped, I think roundabout, like that.
So, if just by, by using a framework, like, like if you use Drupal 7 then you surely have jQuery. Even just by using that, you had so much more bites go over the wire, essentially that now optimizing your little custom CSS that has been able to edit to Drupal site is not a huge win, in that. Somewhat on JavaScript for example can be tree shaped.
That means only those parts that are actually used by the system will be compiled in your bundle. That's all great. But here we come back to performance optimization. Performance [00:12:00] optimization is a step that comes afterwards. Not the step that comes before. And why should I, as a developer that developed locally, need to optimize my site for production performance and unless everyone tests production performance.
No, usually that's not needed. JavaScript is much, much, much faster than that. V8 has become so fast. All of those JavaScript interpreters are blazingly fast, it's just not needed. So my approach to performance always is, Unless you want to test something specifically that you optimize when needed essentially.
And this is an optional step. Functionality first and best performance in mind, obviously, but then the optimization. So, if I ever have a problem that one of my sites that it's using a non-build approach is getting much slower on production and I need, the speed or the, the, win of all that. It's [00:13:00] very easy to add tooling, to add this build process just for production, even do it while on live.
Drupal was great in the old days in essentially serving and compressed CSS. If it's there, but if there's minified version available, serve it as well. So you could even do it on the fly, like in some Cron process background, et cetera, you wouldn't even need to do it at build time because it's an optional step that is making things better.
Not different.
Michael Meyers: That's a, that's a really important, I think concept and distinction, there are applications that require tooling. There are times you need to bring in tooling, these also aren't mutually exclusive concepts. You can do, you know, really, simple things. In addition to, you know, having tooling, you know, you can mix and match these concepts throughout your application.
I'm eager to get into a demo and see how this works. The background was great. Folks, please join us for part two coming up in a minute here where we're going to talk about, you know, [00:14:00] reducing this complexity specifically with, Preact and HTM. Fabian's is going to walk you through some examples using the Umami default Drupal install.
Please remember to subscribe and share this video out. You can check out our past Tag1 Team Talks at tag1.com/ttt. That's three T's for Tag1 Team Talk. We always love your input ideas suggestions. You can email us at ttt@tag1.com. Fabian, thank you so much for the background. Looking forward to jumping into the examples.
And to everyone who tuned in, thank you for joining us.