Transcript
Joy Clark: Hello everyone, and welcome to a new conversation about software engineering. This is Joy Clark, and today on the CaSE podcast I will be talking with Lucas Dohmen about front-end development. Welcome to the show!
Lucas Dohmen: Hi, Joy.
Joy Clark: First off, we wanna talk about front-end development today... Could you tell us what front-end development is?
Lucas Dohmen: When we are talking about front-end development, what we usually mean is Web front-end development. On the Web, we have technologies that are executed in the browser, and we have technologies that are executed on the back-end or on the server, and when we talk about front-end, we mean technologies like HTML, CSS and JavaScript, which are executed in the browser of the user.
Joy Clark: How would you describe yourself? Do you do mainly front-end development, or mainly back-end development, or both? Or none...?
Lucas Dohmen: I think I do both, and I switch between front-end and back-end between projects, and between jobs... In the job before I started to be a consultant, I worked at a database company and wrote a database. I'm very interested in the Web, and I do everything that's related to the Web, both databases, back-end development and front-end development.
Joy Clark: I hang out with a lot of back-end developers - I've been called a back-end developer at some point in my life - and I think a common misconception is... There's a common misconception among back-end developers that front-end is not as difficult as back-end. Would you have any response to that… odd claim...
Lucas Dohmen: I think that it's weird that people say that. It changed a little bit over the last couple of years, and people now think that front-end is not that simple because they see all those complex JavaScript front-end frameworks... But apart from that, people still think for example CSS is easy. On the other hand, I see a lot of people that are mainly back-end developers that still post this GIF of this guy that changes -- this Family Guy GIF where it says "CSS is very complex" or "When I change something, everything breaks", and sometimes those are the same kind of people that say "CSS is simple, and I don't want to deal with it because it's too simple. I'm a "real" developer." At the same time, they say "I can't change something in CSS because it breaks the entire page."
Lucas Dohmen: So I think in a way it's more complex to write front-end than back-end, because you have a less controlled environment. If you think about your server-side language, no matter -- even if it's JavaScript, it's very controlled compared to the front-end, because you can choose what Node.js version you are using, or what JVM version you are using. If you are on the client-side on the other hand, you have no control over that; you can't say "I need version 1.5 of JavaScript", because nothing like that exists, so you can't do that.
Lucas Dohmen: You have to do a lot more testing of different setups than you have to do on your back-end, because normally you have the same setup in production and on staging and on your local machine, basically. This is where the front-end gets very complex. I'm not saying that back-end development is easy, but front-end has its own complexity, and especially good, maintainable CSS is very hard, and you need to put a lot of effort into it.
Joy Clark: Could you briefly describe -- you mentioned the building blocks: HTML, CSS and JavaScript... Could you briefly describe what they are?
Lucas Dohmen: HTML is a markup language, and it is a structured way of expressing content, basically. With this representation, you can now do something with it, for example you can style it. If you want to style it and you want to put it into a layout, you want to put colors into it and stuff like that, you will use CSS. And then there's JavaScript, and JavaScript was intended to be used as a language to add behavior to this HTML and CSS construct that is not part of the browser... But nowadays some people prefer to use it as basically the entire front-end, where it is basically the engine of the front-end.
Joy Clark: It sounds like even in the front-end there's different kinds of architectures... Is that true?
Lucas Dohmen: Yes, that's very true, because there are very different frameworks, and libraries that you can use, but at a fundamental level you have to make one decision, and that is "Where do I produce the HTML code?" because the "classic" approach is to produce HTML on the server and send it to our client. This is how it was supposed to be done when the Web was invented, basically.
Lucas Dohmen: Some people say that this is inefficient, and they prefer to create the HTML on the front-end. Basically, they consume some kind of JSON API, for example, and then they create HTML in the browser. This has advantages and disadvantages, and some people say that this is the “modern” approach... I would disagree. It's just a different approach. Those are basically the two different styles that we have.
Joy Clark: Could you talk a little bit about the benefits and downsides of those two approaches? You mentioned rendering HTML on the server side, and the rendering on the client side... Could you talk about the pros and cons of those two approaches?
Lucas Dohmen: One thing that's a common misconception is that producing the HTML on the server side is somehow inefficient, because you push more data to the client, which is in my experience not true, because JSON is not smaller than HTML, especially when you use something like GZIP, because all the tags will basically be gone from the GZIP version of the data. So I think that they are both very similar in that regard.
Lucas Dohmen: A problem that the JavaScript version has is that if JavaScript is not available or the script breaks, for example, it throws an exception, then the front-end will not be responsive. I from time to time visit the page, and it's just a white page, and there's no error message, there's nothing, it's just empty, and that's basically a very early exception that was thrown in a single-page application. That's a common way to describe those applications.
Lucas Dohmen: That's a problem that people try to solve in different ways. One approach is to render the JavaScript that you're executing in the browser on the server as well, and then first send this HTML over, and also the JSON, and then you have a static version of the page, basically, and you still have this interaction model. But this, of course, increases the complexity of your setup, because now you'll also have to do the server-side rendering, you'll have to have a framework that understands how to change the HTML that was sent to the browser in a way that is compatible to the HTML that was sent, and it doesn't change the fundamental problem because if now at a later stage a problem occurs, the front-end will not be responsive.
Lucas Dohmen: That's why I personally think that the client-rendered Web applications are less resilient to failures than the server-side rendered ones. Reasons why people still prefer that is that on the one hand, they want to have faster interactions. Imagine that you, for example, have a text field and markdown previewer to the right. If you now have the really classic server-rendered version, you would always need to send the markdown to the server and receive it back, right? If you however had a markdown parser on the client then you can show it directly. There's no network between that.
Lucas Dohmen: Depending on the UX or the front-end complexity of your framework, it is possible that it makes sense to at least partially move your application to the front-end. If you, for example, build the next Photoshop, it would not make a lot of sense to make that as a server-side rendered application, because every stroke you make with your paintbrush would be sent to the server, and sent back, and then you see the result. That would be very inefficient. But if you think about most Web applications, this is not the normal use case. And still, if you do server-rendered applications, it doesn't mean that you don't write any JavaScript, because you still write JavaScript, but you would write less JavaScript and it would probably not have as much business logic inside the client. Because that's one of the results of that, because you cannot trust the client.
Lucas Dohmen: If you would have authentication logic and executed on the client, you always need to do that on the server as well, because you cannot trust the client to be mangled with or changed with... And this is why a lot of those client-side rendered applications have a lot of duplicate logic between the server and the client, and that's why I personally prefer the server-rendered way. But I see applications where it makes sense... Games, for example, don't make sense for a server-rendered version, or Google Maps, for example.
Joy Clark: So is it possible to write Web applications without JavaScript?
Lucas Dohmen: Yes, it is possible... I would say that it is something that people have forgotten how to do, because in a lot of cases you don't need JavaScript. Nowadays, a lot of very powerful HTML elements are available to us. If you want to play a piece of audio, for example, with an audio player, there's a ready-made HTML element. You don't need any JavaScript to play that piece of audio, and press pause, and stuff like that. A lot of pages don't need that.
Lucas Dohmen: A blog, for example, doesn't need any JavaScript, in my opinion... The normal, not super-fancy blog just needs to render text in a nice way, with a nice layout, and that's all done with HTML and CSS. One area where it also is no longer necessary is animations, because animations can be made with CSS, and they are normally just more efficient, because it is supported by the GPU of your computer or your mobile phone, and it will be nicer to the batteries of your customers. So there are a lot of things that we no longer need JavaScript for.
Lucas Dohmen: I would not say that you should not write JavaScript, but I would always advise people to think twice about it... Because if you compare JavaScript, for example, to CSS, JavaScript is much less resilient. If for example you put a typo into the “background” of your CSS, what the browser will do is it will not throw an exception, it will not crash, it will just ignore that line in your CSS... Because CSS is a declarative language, and if some of the statements don't work in that particular browser because maybe it's an old browser that doesn't know border-radius, for example - that would be a very old browser, but nonetheless - then the application will continue to work, it will just not have this one feature, this one thing. But if in your JavaScript you mistype some library name, then it will just crash, right? And it cannot just go on, because it's not a declarative language. It will need to execute all the statements in the JavaScript, and that's where I would try to first look into what does my browser natively support, and if it supports it, is it good enough for my use case? ...and then use that, instead of building your own JavaScript for it.
Joy Clark: Interesting. We did an episode with Jen Simmons (episode number one of the CaSE Podcast) for anyone who's interested in hearing more about CSS; I think that episode turned out pretty well.
Joy Clark: So we're able to develop Web applications without JavaScript... Where does JavaScript then come into play? If I can do it without JavaScript, why would I do it with JavaScript?
Lucas Dohmen: Let's say that you have some interactive element that does not exist in HTML. Let's say you want to have a board of cards, and you can drag and drop your cards from one space to the other. Then it would be very nice, because it's a nice user experience to just drag and drop your cards from one place to another and not just click on it and say "Move two lanes etc." and then move it there. And in this case you could write a piece of JavaScript that makes it drag- and droppable.
Lucas Dohmen: Modern browsers have a very nice way to do those enhancements, which is called Custom Elements. Custom Elements are basically new HTML elements that you yourself have made up, and you implement how they work in JavaScript. It looks like a normal HTML tag that just doesn't exist in the normal world, and you then write the code on how it works. This is how I personally prefer to use JavaScript, basically as a way of teaching the browser about new things that it doesn't know about, basically.
Joy Clark: So there's the server-side rendered apps, and the client-side rendered apps, and I'm thinking about how does the -- when we're developing Web applications, we're talking about front-end development... But does that mean we get to ignore the back-end completely?
Lucas Dohmen: Yeah, that's one of the reasons why some people want to do client-side rendered applications. If you have developers that don't want to interact with front-end, they just want to do back-end, it is a very easy way to just say that "We have an API, and this API produces JSON or XML or something" and then there is a (separate) front-end team, and that talks to this API. And then we have a very clear cut between those two teams.
Lucas Dohmen: Some people think that's desirable, because they want to have a fancy microservice architecture with 500 services, and our front-end talks to those services. But I think that this kind of architecture is a product of an architect that doesn't think that front-end is a complex topic. Because why would you cut your back-end into 500 services, but only have one application that is the front-end? For me, that just means that you think that it's so much easier and so much smaller that it doesn't need to be cut into multiple pieces.
Lucas Dohmen: A different approach would be to say that you have let's say 10 services, but each of them produces their own HTML and delivers it to the client, and then it's basically a question of how to jump between those systems and how to integrate that, and that means that a team that works on this one system consists of both front-end and back-end developers, but they work together and they can create a system that if they want to deploy a new version, they only need to deploy that new version. Because if you compare that to the version where you have a front-end team, that has the front-end "monolith", then a change will probably also be made to the front-end and to the back-end. The teams need to coordinate that change, so they need a new field in the API, and when that field is available, then the front-end team can do something with that field, or something like that.
Lucas Dohmen: That's where I would prefer to have a cross-functional team, basically, that works together on one part of the application, that is cut into multiple pieces. Some colleagues also have that idea, and they call that kind of architecture Self Contained Systems. We can link that in the show notes. It's basically an architectural style where you cut the application not into front-end and back-end, but into different pieces.
Lucas Dohmen: I also saw customers that previously had back-ends, and then a Java desktop application, basically, and for them the jump to a client-side rendered application was conceptually much smaller, because it's the same architecture as they had before. It has advantages and disadvantages. If you say that the team just wants to keep on working the same way they did before and the back-end people can just continue working as they did before, then maybe you want to have a single-page application in the front-end that basically is that architecture... But I would argue that if you want to move from your Java application to a Web application, then you have to rethink some of the parts of your application basically, and make it more Web.
Joy Clark: When you're talking about cutting little pieces apart from each other, how do you work...? I'm thinking about user experience. Even if it's one application, I think a lot of what you probably have to do when you're developing a front-end is to think a lot about the user experience... And I can think that when we cut it into different services, then we have to think even more about the user experiences over all of the services... Could you talk about how you can do that?
Lucas Dohmen: An important part of that is to have, on the one hand, a similar look and feel between the systems. If I have four different applications and they all should look the same way, then they need to share some CSS and maybe some JavaScript between those applications. And a common way to do that is the so-called style guide.
Lucas Dohmen: A style guide means different things to different people, but one definition of a style guide is basically that you have a centralized catalog of elements, for example a header, and a top navigation bar, and stuff like that. The style guide lists all those different elements, and you can then, as a back-end developer, just pick and choose elements from that, and say "Okay, I need this kind of markup to show a nice top bar. I don't need to write any CSS, I don't need to write any JavaScript, I just pull from that catalog."
Lucas Dohmen: One thing that a lot of people have seen in that way is Bootstrap, basically, but because if you want to use Bootstrap, you put in the CSS and the JavaScript, and then you open the Bootstrap documentation and you look up "How do I create a card?" and then you copy your markup into your code, and it looks the way that Bootstrap made it.
Lucas Dohmen: As a company, you can basically create your own Bootstrap, your own style guide, and then tell the different teams "This is the catalog of things that you can use", and then they will look the way that the style team or design team has intended it to look. There are different approaches to how to do that.
Lucas Dohmen: One question is: Do you allow the teams to add their own CSS and JavaScript to the mix? If you allow that, then you need to come up with a way that it doesn't clash, basically. But I would say that you almost always need a way to do that, because there will always be some elements that are only necessary in one of the systems, and also you need a new element, and you don't want to wait until it is available in this central style guide, and then add it later; you want to do that now, and maybe before going into production, you will then extract it and put it into the style guide. But you want to be able to add something, so you have to find a solution for that.
Lucas Dohmen: Two ways to do that are you either provide all the CSS and JavaScript as an NPM package; NPM is the package manager for Node, like Maven, I think... I don't know, I'm not a Java developer. But you install packages basically, and then your application imports those packages and delivers the CSS and JavaScript. That's one approach.
Lucas Dohmen: The other approach is that you put the CSS and JavaScript on a central server, and all applications just reference that CSS and JavaScript. In both cases, you need to make sure that you have a versioned style guide, basically. So if something is added to the style guide, it is not automatically delivered to all the clients, to all the systems, but the systems can opt into updating.
Lucas Dohmen: If I have version 1.3 now, then I can choose to update tomorrow, and the other team can choose to update today, because they have time. Of course, you need to make sure that the versions don't split apart too much, because if one of the systems uses version one and the other one uses seven, then they will look very different, and the look and feel will not be the same... But it should be okay that one of the teams updates today and the other team updates in one week, for example, because they have an important deadline they need to meet.
Lucas Dohmen: This is possible in both the NPM version, because you can just release a new version of the package, but it's also possible in the central asset version, because you can just have a different URL for different versions of the file, and then the design UX team tells everyone "Okay, there's a new version available. You can now update to the new package."
Joy Clark: What's the relationship between front-end development and design?
Lucas Dohmen: It's a very close relationship. When I started with front-end development, I worked at a company where we had a designer, and she designed in Photoshop and sent me the Photoshop files, and then I sat down and wrote the HTML and CSS to make it look like the Photoshop file. That worked pretty well back then, and there was a clear cut, because I didn't do any design, and she didn't write any code.
Lucas Dohmen: This becomes harder and harder all the time, because nowadays we don't design for a fixed width layout, but we design for thousands of different sizes of devices... So you would need to create different mock-ups for different sizes, therefore you need to collaborate much closer together, because the designer can no longer create a mock-up for all sizes. That would be just too much work. So you have to fill in the gaps between the version for the iPhone and the iPad, what happens on those scales.
Lucas Dohmen: Designers and front-end developers need to work much closer together nowadays, because they need to communicate about what happens in those cases between. Some people say that a designer nowadays needs to be able to write HTML and CSS. I would disagree. I would say that it helps a lot, because then you have a better understanding on how it works, but I would not say that you need to be an expert CSS coder to be a good Web designer. I still think that those are two different roles, and some people are able to fill both roles.
Lucas Dohmen: I, for example, am not a very good designer, but I can put all designer things into HTML and CSS that works very well. I think that's still possible and I think that's still necessary, because they are different skillsets. Being a good designer is a different skillset than being a good CSS developer, for example. But I think we need to work closely together to make sure that both we know the limitations, and also know the new capabilities that a browser has. So if there is a new cool CSS feature, then this could be a good inspiration to a designer, because now they see "Oh, cool, we can now do this, and I didn't know that Websites can do that, so let's bring that into our product."
Lucas Dohmen: The same thing goes for UX designers. This is also a different role, but as a front-end developer, you need to be able to talk to both designers and UX people to bring all those different parts into code and into life, and I think it makes sense to learn about graphic design, about UX as a front-end developer, but I don't think you need to be an expert to be a good front-end developer.
Joy Clark: You were talking about different browsers, and I'm thinking about performance... So what role does performance play when developing front-end applications?
Lucas Dohmen: That's a good question. I think in some ways people underestimate that, because when they talk about performance, they have their tools to measure how fast was the SQL query, and how fast was rendering the JSON or HTML on the server side, but they stop when it comes to the client, and they don't measure anything in the client. I think that's a mistake, because the more interactive and the more interesting things we do in the client, the more we need to pay attention to that. Because if you for example put a lot of JavaScript into the client, it has a lot of performance implications, so you need to make sure that it also works on a maybe slower telephone device.
Lucas Dohmen: The more things you do in the client - the more complex CSS you write, the more complex JavaScript you write, the more testing you need to do with real devices on how they work and how fast they are. Modern browsers like Chrome, they offer a lot of insights into like how long did it take to "paint" this part of the screen, and you can look into that and see which parts do I need to optimize.
Lucas Dohmen: We also need to make sure -- if you write CSS in a way that results in a lot bigger CSS files, then this big CSS file needs to be delivered to the client, which costs a lot of time; then it also needs to be parsed by the browser, and then executed. A small CSS file is always faster than a big CSS file. The same goes for JavaScript. A lot of people underestimate that, but if you have a lot of JavaScript, then your iPhone or Android device will take a lot of time to execute all this code.
Lucas Dohmen: If you as a developer always have the newest hardware, like the newest MacBook Pro and the newest iPhone X, and you only test on those devices, with the fastest internet that's available, then you might think that it's okay from the performance perspective, but maybe also test it under worse circumstances, like a slow internet connection and a five-year-old Android device.
Joy Clark: Do you have a five-year-old Android device sitting at home to check your...? When you do your testing...
Lucas Dohmen: At home I don't have that, but the last customer I worked for, we bought several telephone devices and two tablets, and we tested all our code on all those devices. I think that's necessary, because there's no way that an emulator can really make sure that this is the right performance. You cannot find that on your computer. You will need to do that on a real device, you will need to see, like "If I scroll with my thumb, is it really smooth, or is it slow?" and you can only do that on a real device; there's no other way.
Lucas Dohmen: Even if it's nice to have a service that will render your page on an Android device and on an iPhone and so on to see if there are big CSS errors, for example, where on the one device the border is missing, or something... But to get a feeling for the user experience, and especially for the performance, you need to have real devices. There's no way around that.
Joy Clark: Is there any way you can optimize when you're developing for mobile devices? Because I know that most of the browsers nowadays seem to be -- when I'm at home, I don't usually open my laptop, I just check it on my iPhone, or something like that... And I'm really annoyed when the sites don't look nice on the phone.
Lucas Dohmen: One approach that people have is the so-called mobile-first design, where they say that when you create a new Web application, first create it for the smallest device that exists, because it is always easier to add more things to your application than it is to remove things. So if you start on a 30-inch display, and you design your application for that display, and then you want to make the same page available on your iPad, then you have to throw things out, because otherwise it will be much too crammed on your device.
Lucas Dohmen: One idea that people had was to just start with the smallest device, and then go to the next device size, and maybe add something, or maybe don't; it's okay to just put things in a different position, or make them bigger, or something. Then go to the next size, and to the next size... That's the basic idea of mobile-first design. I think that's still the best approach for designing a system like that.
Lucas Dohmen: I recently saw a project where they started on the big screen, and then later wanted to make it available on phones, and it was much harder, because then they realized that certain elements just don't work on the smaller screen. They look bad, or they need to cut it in a place where it doesn't look good. So start with the smallest device.
Lucas Dohmen: Usually, the smaller devices are also slower than the bigger devices, but it's not necessarily true if you have an iPhone X and a five-year-old computer, basically... But normally, if they are approximately the same age, the smaller device will also be slower, so you can also make sure that you don't need too much performance from the device. So one approach would be to just really start with a slow telephone device, and then go to a bigger, faster device.
Joy Clark: I've also heard the term "offline-first", and I didn't know what that meant. How can a Web application be offline?
Lucas Dohmen: The bigger question is "How can it be mobile-first AND offline-first? What's first now?"
Joy Clark: Mobile-first, offline-second... Offline-first, mobile-second...
Lucas Dohmen: Yeah, maybe. I don't know. I think that this something-first naming scheme is something that people came up with a while ago, and then they continued to put everything first... Like, test-driven development means test-first, basically. I'm not a big fan of this naming scheme, but yeah... What people mean when they say offline-first is that if we have devices that are not always online, then we need to think about a way of handling the offline case.
Lucas Dohmen: For example, you have your to-do list application on your phone, and you go into the supermarket and the connection drops because there's no connection in the supermarket. And if you now cannot access your to-do list items anymore, then you cannot go shopping, right? That's bad. So you need to find a solution on how to do that. And some people said that the best solution is to start with the "I have no connection" case. So in the same way that mobile-first says that first look at the smallest device and then look at the bigger devices, offline-first says "Let's first look at the devices that have no connection, and then look at the devices that have a connection."
Lucas Dohmen: If you want to design your application in an offline-first way, then you have no other choice than to put a lot of logic into your phone, because it now needs to do something when it's offline. If you want to build an application that is offline-capable, then it could also be a server-side rendered application, because now it can for example have caching on the client side. One technology that helped with that problem is service workers.
Lucas Dohmen: Service workers are basically an intelligent cache that you can configure with JavaScript. For example, you can say "If I cannot reach the server, please instead do this." In the example of the to-do application, you could write it in a server-rendered way, and then you could write a service worker that will serve a cached version of the application whenever you're not online, and will maybe also show a banner “offline”, because it might be outdated.
Lucas Dohmen: One problem I have with the offline-first approach is that a lot of people think about the technology problems first, and think about the user problems later... Because if you really do offline-first, then you have a lot of synchronization errors. If we two share a to-do list, for example, and it is an offline-first application, we are both offline, and you check off an element, and I edit the element, what happens when we both go back online? Is the edited item now checked off? Is that okay? Maybe it's not, because you added "and tomatoes" to the "potato" check item, and then it's not okay to just check it off.
Lucas Dohmen: For a simple application it always seems to be very clear on what to do, but the more complex your application becomes, the bigger the write conflicts between those two offline clients become. So we need to first think with the business people and the UX people and the design people "What do we do in a case where two people do something that cannot be resolved?" In a lot of cases, you need to ask your user to resolve that conflict, because you cannot do that in an intelligent way. In some cases you maybe can do it, but I would recommend people to first -- like, before they start with their offline-first application, first start with thinking about the problem cases; what happens when two people edit the same item?
Lucas Dohmen: I feel like showing people a view-only version of something as an offline capability is very useful, because if I sit on a train and I just want to quickly look into my to-do list, I want to see the to-do list, and I just don't want to see a “you’re offline” message. But if I then want to add something to the to-do list, then maybe I need to wait until I'm online, or it can be queued on your client, for example, and sent to the server later. But that's a different kind of offline capability than really saying "I'm offline-first and the application works on the client no matter if the server exists or not."
Joy Clark: Accessibility is a huge topic nowadays... Well, I don't know if nowadays; it should have always been a huge topic. But when we're talking about Web development front-ends, we're talking about creating a Web page, and how can we really make sure that we're inclusive for all of the users who come to our Web page?
Lucas Dohmen: The thing about that is that HTML on its own is very accessible. If you write no CSS, no JavaScript, just HTML, then it's probably something that everyone can use. A screen reader will be fine with it, a user that needs a much bigger font size because they don't see as well anymore will be able to use it, and people with color blindness will be able to use them... But as soon as we start with CSS and JavaScript, then we start with problems, where we make something less usable for someone who has different needs than I have, for example.
Lucas Dohmen: This is why I always try to first create something with just HTML, and really do it this progressive enhancement style. Progressive enhancement basically means we have a baseline version that will work everywhere; it will work in the oldest Internet Explorer, it will work in...
Joy Clark: Wow...
Lucas Dohmen: ...everything. Maybe not everything will work, maybe the date picker will just be a text input field, but it will work, basically. And then progressive enhancement adds layers on top of that, and improvements that make it nicer to use, that make it look beautiful, and stuff like that.
Lucas Dohmen: If you follow this approach, then you start with a very minimal HTML-only version that will probably be accessible on its own. And if you then add a layer, then you need to think about what did I change about my markup, for example, that makes it impossible to use without CSS? Or you add a hint that is only in CSS, but there is nothing in the markup that says there is an error on that field. Always think about the HTML first, because that's the most accessible thing that is in your tool belt. That's the one thing I want to say about accessibility.
Lucas Dohmen: The other thing is to just do testing, because if you have a modern device, it will probably have built-in capabilities for blind users, for example. If you have an iPhone, you can put it into a blind user mode and try out how your application works... Because that's the only way to make sure that it works. Try to use your application without the mouse. Does it work or doesn't it work? Because there are people that cannot use a mouse, because their hands are too shaky for using a mouse. They prefer to use a keyboard. Try to use your Tab key to move through your application. Does it make any sense, or are you jumping around on the page? Accessibility would be a topic for another --
Joy Clark: Yes, it is a very large topic.
Lucas Dohmen: Yes, but I can put in two suggestions of books to read about that topic into the show notes. It's an important topic also from a business perspective. A lot of people think that accessibility is something you do because you are a good person, basically, but there is also an argument if you are just a business person that doesn't care about being a nice person... Not all business people.
Joy Clark: I'm a business person who is also a good person.
Lucas Dohmen: Then still there's a case for putting a lot of effort into accessibility, because they are customers, and if they cannot use your page, you will lose customers. So I think it makes sense to put effort into doing that. And just to make it clear, if you write an application in a client-side-rendered way, you can still make it extremely accessible. You can just do that, but probably it will be a little bit harder, from my experience... But it is possible, and you should do that.
Joy Clark: What's the next big thing in front-end development which we're looking out for?
Lucas Dohmen: One thing that's happening right now is CSS Grid, which changes a lot of things about the way that we can do layouts on the Web. It makes layouts on the Web much more exciting. You can do things that didn't work before. And also, it enables us to build Websites that are really responsive... From the smallest viewport to the biggest viewport, there's a layout that works on all those devices, without writing a lot of special case code for a smaller screen, a bigger screen, and stuff like that.
Lucas Dohmen: I think it's almost impossible to describe CSS Grid in an audio format, but I would suggest to watch talks about that on YouTube, for example. I will also put something in the show notes for that, because there's a great YouTube series by Jen Simmons where she shows what you can now do with CSS that you couldn't do before. I think this is a bigger revolution than most people think, because we really can do things that didn't work before.
Joy Clark: I think we covered quite a few aspects of front-end development. My question now is "How do I go about developing a front-end application?" What tools are available? What's your usual workflow?
Lucas Dohmen: I think that it is almost scary to people, because they google for "How do I put all my CSS files into one file?" and then they see a thousand different ways on how to do that, and a thousand different tools that will do that. That makes front-end scary, in a way.
Lucas Dohmen: What I usually do is I write my CSS using SCSS, which is a language that translates to CSS; some people call it a preprocessor. It adds some nice things, like imports statements, or variables, and nesting, and stuff like that. If you want to write a bigger CSS project, I would definitely suggest that you look into SCSS, because it makes a lot of things easier.
Lucas Dohmen: There are other alternatives to that, like Stylus and other languages... I just really like SCSS, but I think Stylus is fine as well if you prefer that. One advantage that SCSS has over the other solutions is that Bootstrap is written in SCSS, so if you for example want to base your application on Bootstrap and then extend onto that, then if you use SCSS you can for example only import certain parts of Bootstrap, and basically throw away all of the things that you don't need.
Lucas Dohmen: That's something that I did in the last project, for example. We started with a lot of Bootstrap components, and did like a first draft of the Web application - how should it look - and then there were a lot of things where the client said "I want to have something different than the Bootstrap component." So we threw out the Bootstrap component, wrote our own component... But yes, the baseline of Bootstrap was still there.
Lucas Dohmen: I think that Bootstrap is a good base on which to start your CSS. It gives you a certain structure, you can have your color names and stuff like that, and that's why I mostly do Bootstrap-based design. But I don't just put in the whole CSS of Bootstrap, but I import it from my SCSS, and then I can pick and choose from Bootstrap.
Lucas Dohmen: On the JavaScript side, you also have the problem that you maybe don't want to write a lot of different files, and then put them together into a few files or one file of JavaScript, so you need something like a bundler. A very common one for that is Webpack, but there are other ones as well, like Rollup, for example. They have the goal to put all your CSS files into one CSS files and all your JavaScript files into one JavaScript file. But all those tools - you have to learn about them, you have to study them.
Lucas Dohmen: I want to make that easier for people, that's why I started a project that we can talk about in a minute. But before that, one important part of my approach to front-end is a component-based approach. A component-based approach means that I try to cut the entire page into small pieces; in the same way we do it on the back-end basically, we just don't write everything in one file, in one class, in one function etc. but we put it into smaller pieces. Then we re-use that piece to build a bigger piece, and a bigger piece, and a bigger piece. That's the idea of component-based front-ends.
Lucas Dohmen: A component for me consists of HTML, CSS and JavaScript. Those three things belong together, and I usually have a CSS file that corresponds to an HTML template, or a partial or whatever it's called in that language, and a JavaScript file that extends that. Each of those can be then developed in isolation, so I can for example build the perfect button on its own, and then I can use it in all kinds of places. This is where a style guide can help, as well. In a style guide you always write the components, and then later on in the application you can put them together and use them together.
Joy Clark: So a style guide is also a tool.
Lucas Dohmen: A style guide is a tool, right. There are different tools that can help you build your style guide. Some people start with the components in the style guide and then put them into their application. Some people start with the application and then extract them to the style guide... I think that to start with a style guide has its advantages, because you start at the small component level and you can look at it in isolation, make it bigger, make it smaller, and get a feeling for that.
Lucas Dohmen: One approach to put those into categories is atomic design. Atomic design says there are very small components, and then you can use bigger components that use those small components. There's an interesting book about that called Atomic Design which explains how to do that. I would recommend looking into that, especially if you are a designer or UX person, because I think it has influence on your work as well. So if you create a design with atomic design in the back of your head, then it will probably be easier to implement for the people that later write the HTML and CSS.
Joy Clark: What's your favorite style guide? Or maybe you have more than one...
Lucas Dohmen: Do you mean a style guide, or do you mean a software to create style guides?
Joy Clark: A software to create style guides... Or if you have a favorite style guide, you can share that, too. I meant the tool, but...
Lucas Dohmen: Okay. A tool I really like for that is called Fractal. It has some weird things about it, but from all the tools I've tried so far, I like it the most. I'm not a huge Fractal fan, but I would say it's a good tool and it works pretty well.
Joy Clark: I'm really excited to ask you about this, because you developed a tool for developing asset pipelines, and I really love it.
Lucas Dohmen: Thank you.
Joy Clark: That's just me interjecting... So could you tell us a little bit about your project?
Lucas Dohmen: One thing that I said before is that the amount of tools and the things you need to read and stuff like that is so much that people tend to either not do it at all, or need to ask someone to set it up for them, or stuff like that. Because they want to write modern JavaScript, but compile it to JavaScript that also works for your old devices, for example. If you wanted to have all those things, then you have to put a lot of pieces together.
Lucas Dohmen: Then you google on Stack Overflow, then you copy some code; you don't really understand what's going on there, but you copy into your code anyways, and then you are in a mess, basically.
Lucas Dohmen: A colleague of mine, Frederik Dohr, and I - we started a project called faucet-pipeline. faucet-pipeline basically is a tool that is based on the tools that we think are currently the best tools for that... And it provides a very simple configuration format to configure a few things about it, but not everything - that's part of the design, that it's not allowing you to do everything. And then it does all the things that it needs to do with the tools beneath it and puts out CSS, JavaScript and images.
Lucas Dohmen: If you use faucet-pipeline, you can choose for example to have a JavaScript pipeline. If you don't need it, you can just not install it. You can have a SCSS pipeline, a pipeline for images and a pipeline for static files. And there's also a variant of the JavaScript pipeline for TypeScript if you prefer TypeScript, for example.
Lucas Dohmen: All those pipelines just take basically a source, which is a path to a file, and a target where it should put the resulting file. A lot of people at INNOQ, the company I work for, they use that in the project and they are very happy with that. An old customer also uses it in production and they also really like it, so I'm confident that it helps a lot of people. The goal is not to write a pipeline that works for everything, but for like 95% of projects. So it will not work if you have a really complex JavaScript front-end where you want to split it into 15 different files, and lazy-load something, and stuff like that... But for most projects, it will solve your problem without you needing to write a lot of configuration files, and stuff like that.
Lucas Dohmen: We are moving towards 1.0. Maybe when this podcast is released, 1.0 will be released. We are currently working on the release candidate, and we're testing it very thoroughly, and also writing a lot of documentation so everyone understands everything that's going on. One design goal is if we at some point want to change something under the hood - for example, we use Rollup for putting all the JavaScript files into one JavaScript file - if a better tool comes up, that works faster or makes smaller files, then we can change the way that it works under the hood and you don't need to change anything about your code or your configuration file. That's one design goal of the application.
Joy Clark: It sounds like all asset pipelines should have been implemented like that from the beginning.
Lucas Dohmen: Yeah, I don't know...
Joy Clark: Well, I think that's all of the questions I had for you. Is there anything else you would like to say about Web development?
Lucas Dohmen: I think that if you are a back-end developer that never did front-end, try it out. Try to read about CSS architecture, for example, and not just complain about it or talk about it like it's too easy to be relevant to a "real developer." I really hate the term "real developer", because I think all developers are real developers. Just try it out, and don't just think that CSS can never be maintainable. I think that's wrong. You can do that in a good way, but you need to pay the same attention to that as you pay to your back-end code. Because if you would just write your Java code like some people write their CSS code, it would also not be maintainable.
Joy Clark: Oh, I have bad pictures in my head right now...
Lucas Dohmen: Yes, that would be my conclusion, basically.
Joy Clark: You mentioned a couple of books during the podcast, and resources - we'll definitely link those in the show notes. Are there any other books or resources that you'd like to recommend?
Lucas Dohmen: Yes, there's a really good online book called Resilient Web Design. It's a little bit like a history of the Web, but also a lot of philosophy of the Web, like "How do we write applications that work very well in all browsers?" I would recommend that; it's free online, so we will link that. And there are a lot of good books from A Book Apart. They write books about CSS, design, user experience and stuff like that. I read multiple books from A Book Apart, and all of them were very good, so I can recommend that as well.
Joy Clark: Well, thank you very much for your time.
Lucas Dohmen: Thank you!
Joy Clark: To all our listeners, until next time!