Tech Talk: "How to pick the next Front End Framework" mit Tomi Močnik von TimeTac

Tech Talk: "How to pick the next Front End Framework" mit Tomi Močnik von TimeTac

Alright, hi! Welcome to the talk on the topic of how to pick the next front end framework for your project.

Let me first introduce myself, I'm Tomi Močnik, lead front end developer at TimeTac. I have over 12 years of experience in web development and I came to TimeTac almost 8 years ago, with just some basic CMS knowledge but then grew into a lead who helped transfer from an old framework ExtJS to React. Before I start, I'm going to give you just a quick preview on what I am going to talk about. So, first a quick introduction followed by why and when, how to switch, finally making the decision, I will also briefly talk about prototyping and in the end enjoying the new framework.

A quick word about my company – so TimeTac is a leading time and attendance software as a service provider, which empowers everyone to focus on the most valuable resources, that's time. We are providing mobile and web desktop clients for our software to our 80.000 users.

First, a short background story; we are a service provider with a long living complex product, we a have stable and continually growing customer base. We still provide new features, customization and work on improvements all the time. And we were put in front of a dilemma: stick with the current framework, slowly migrate, or start from scratch. And yes, we then decided for the option 3.

So I just want to clear some things, before we start. What I am not going to talk about, is if you should use a framework, if you should go with vanilla JS or write your own framework. I'm also not going to tell you

which framework is the best, or what tools are the best and why. And I can also not give you any advice on how to convince your management to actually do this switch.

Now that we have the baseline covered, let's jump right into the why and when:

Why would someone even want to switch to framework? Biggest issue, or the most pressuring one is the unsupported framework – they change everyday, some are better built than others, and those then eventually fade out and yeah, are considered outdated. Probably one of the most common reasons is also an old codebase, that is hard to maintain. No one knows what's going on with that, and it's not covered with any automatic tests. Some might also face issues with performance that they can not solve with the current framework – or as already mentioned, some frameworks are built better and more modern and are more fun to work with. And others are not and that's why the jobmarket is actually changing or shifting, some developers just don't want work with old frameworks anymore.

Now that we know we want to change or to switch the framework, when is actually the correct time to do the switch? In my opinion, you should have a stable product with enough revenue to cover the cost of the rewrite, changing the framework just because a new one was released yesterday, is in my opinion, not the best solution because you should have a product, you should have customers that are using it, and to actually get paid and be able to cover the costs. You should have a clear vision – or like a feature freeze on the current state on what you are going to still support in the previous one. Or what will be migrated, what should be done with the new framework. We also have to have resources; rewriting a framework or working with a new framework

is really demanding on the developers. So you have to have the development resources to be able to afford the change. And of course, everyone should be on board with that change – from developers to management. As with all big changes, the longer you wait, the harder it gets in the end.

Okay, now we know that we want to switch, we have a rough idea when to switch, let's actually then find out what's maybe one of the best approaches to do it. I recommend to do indepth research – as I already said, what are the requirements, are we just changing the look and feel of the app, are we just rewriting the framework, will it look the same but – let's say – with a different background, what components do we need, what do we use, what technologies do we need and so on. Then the next step is to actually see what is out there, what frameworks are available, what are the trends, what developers actually want to use in the future. As I said, is there a job market for the framework? How likely is it that somebody is already using it and knows it, will it at the end fit in the current stack? And it's not just the framework switch, it's also a knowledge switch. So, learning a new framework is time consuming, do other developers maybe already have some experience with some of the frameworks? That would be beneficial in the beginning because you could get started at the project sooner. And, in the end, what's also important is to ask the team, get their opinions and decide upon that.

So, what were our requirements? For us it was important that it has a future and it has a stable user base. We needed components like grids, dialogues, calenders and advanced data views. Those are then either built in or as add-ons. For us it was also important that we get development support, or development tools to support the developers, to compile or whatever. We also checked the cost, if it's not an open source project, how much is it, are there are additional components or libraries that have to be purchased? And maybe one of the requirements, that is maybe missed, is a good documentation. It is really important that the documentation is easy to use, up to date, and understandable.

So, anyone that is working with front end frameworks probably knows that there are as many frameworks as there are developers. So, how the hell should we then be actually pick as the right one for us? Depending on the project, most probably we will be looking into the mainstream frameworks.

But still – where should we start?

I would suggest that trends and surveys are a good starting point. So, stateofjs.com is doing yearly surveys. They are asking developers what they want to work with, what they are working on, which frameworks they enjoy or hate and also tools and so on. And, how popular it is, how big is the community.

And if you look at the graph, we can clearly see the winner here; So thats an easy pick – Svelte it is. We are done, right.

Yeah its not that easy I would say.

It's not easy – yes – but it gives you a rough outline where the future goes, where people's knowledge is moving, and there's always room for less known frameworks but the risk that it gets outdated is a bit higher.

So, setting the trends and opinions aside, we can also measure some of the indicators based on some hard facts and raw data. Like for example, how big is the community, who is standing behind the project, GitHub activities and statistics, version cycles, who from the bigger names is using it, number of tutorials, videos, blogposts and so on – and of course the number of job postings, which is special important for a growing company. Because if you are looking for new developers and they are using some frameworks that are more known, it will be highly likely that you will get them more easily.

So what will then be the best approach to combine all this data? For us it was a big spreadsheet. In the end we are engineers, we can measure things easily and so we just used different weights for different things which we find important. So how did we tackle it? We wrote down all the raw data, the trends, the survey results, the opinions, pluses, minuses and in the end evaluated all of it. For us it was important who was standing behind the project, because that would give some more "calmness" in the future. How active the community is – so how much is it used, how many stars it has on GitHub and so on. What UI components are already in the box, do we have to purchase or do we get some more. And, in the end we also took a look at our state management and performance topics.

Based on that first drilldown, we could already eliminate some of those choices; and we were left with the big 3, that probably everyone knows: it's highly likely that you will get the same decision if you have a bigger project. So, you you even might start this evaluation from this point on – if not, I would suggest that you remove some or eliminate some of the choices early on, to then have better results at the end. But, in the end, we picked those 3 – Angular, Vue.js and React – mainly on future-proofness and available resources, some more or less raw data, hard facts with a pinch of trends.

So now that we can concentrate on the 3, we started checking the fit in into our stack and the company. That means that we will check on how it can integrate, in what current stack do we need to additional infrastructure or any tools. Does it mean large knowledge shifts, because, yeah, we were switching from ExtJS. So that would mean that a lot of developers would have to learn a new framework. And we will also have to probably hire some experts to easily kick off the switch. So for us it was the highest priority that we choose a framework that the current front end team would be willing to work with. That's why we then decided to make an internal survey; we asked our developers to share their skill, and skill sets and experience on those 3. After getting the data, we found out that we can already eliminate one of the frameworks, because employees had just more knowledge on the other 2.

This decision might be different from project to project, but for us it meant that the initial kick-off would be easier with the knowledge at hand.

So, there are only 2 left now – beside the knowledge lack, Angular was also showing the most resistance in the community, because of major rewrites and a deeper learning curve.

Now we get to the final battle where we then decided between those 2 – Vue.js or React. We actually then ask our developers what they think, what else would they rather work with, in my opinion it should never be just be a top-down decision, the developers should also have a voice. Yes, for TimeTac it was important that we listen to the front end experts, and trust them. As in the end, they will have to work with the framework.

So, it's now time to make the decision; for us the winner is and was React, based on all the data, surveys, feedback and discussion, we could then make a decision that we can stand behind. Additionally to the pick of the framework, we also decided to start the project on a TypeScript base, that's actually one thing that we didn't consider in the beginning, but should be one of the major criteriums.

Before we could switch, we wanted to make some prototypes to get everybody on board with React. So, we organized a company Hackathon. The goal was really simple; create a proof concept for features, that way we could see how fast we can apdopt it, how much knowledge we already have in the team, and we could more easily say we've made the correct decision.

Did we choose the right one? At this point, I hope we did! It's hard to know or even not possible, that's why I suggest that the team does cycles of observation, evaluation and reconsideration. If they see that they are hitting a limit – technical limit or they just have a feeling that thats not the best decision – switch fast and without hard feelings.

If everything goes as planned and we are sure to kick off the product with the new framework, it's actually then time to enjoy it!

So, for us that meant that we came to new dilemmas – how to then actually extend React to our needs. So we started gathering new data, picking additional tools and libraries – of course new and exciting ones. This was then done within developers itself, so

we were indicating what we want, we did quick evaluations, with short proof of concepts, and by the end we had this list. So for state management we used Redux, routing with React router, Material UI for the UI and base components, Luxon

as a date wrapper, RxJS for callback based code, Jest + Testing Library for automated tests, our own open source project for communication with back end, Electron for the desktop clients, Fullcalendar for calendar view, and of course Gitlab pipelines for all the fancy running tests, linting and of course deploying to production.

Final words: One thing before closing, it's important to always listen to your team, if something has to change to a final solution that works for everyone. Thats why in TimeTac each employee's opinion matters. With weekly front end teaparties we

discuss new libraries, new tools, how we can include them in the project, and get the best out of it. We got our info, make proof of concepts, work on changes and incoorperate them as possible.

The summary once more is: do your research! Research the market and the requirements, drill down on the available data, ask your team, make a choice and prototype it. And in the end, enjoy it!

I hope this was helpful to someone that is dealing with the same dilemma, we had at TimeTac and have a nice day, bye!

 

 

Erfahre mehr zum DevTeam von TimeTac