How to Pick the Next Front‑End Framework: A Practical Playbook from “How to pick the next Front End Framework” by Tomi Močnik (TimeTac)

Context: A long‑lived product faces a pivotal choice

In “How to pick the next Front End Framework,” Tomi Močnik, Lead Front End Developer at TimeTac, walks through a decision process many engineering teams eventually face: when and how to switch your front‑end framework—and which one to choose. TimeTac provides a time and attendance SaaS with mobile and web desktop clients, serving over 80,000 users. It’s a complex, long‑lived product with a stable, growing customer base, constant feature work, customizations, and ongoing improvements.

Within that reality, the team hit the familiar fork in the road: stick with the current framework, slowly migrate—or start from scratch. They chose option three: a fresh start. Tomi is crystal clear about what the talk is not about: it’s not a debate about Vanilla JS or writing your own framework; it’s not a ranking of “the best framework” or a tool showdown; and it’s not advice on how to persuade management. Instead, he focuses on a grounded, team‑driven process that blends technical facts, product needs, and the human factor.

Why switch at all? The most common triggers

The talk calls out the drivers that typically force the issue in real products:

• Unsupported framework: frameworks evolve constantly. Some fade and become outdated or unmaintained.
• Old, hard‑to‑maintain codebase: legacy code with no tests, no ownership, and little clarity is a liability for quality and delivery speed.
• Performance issues you cannot solve in the current framework.
• Developer market and motivation: modern frameworks can be better built and more enjoyable; many developers prefer not to work with outdated stacks—and the job market reflects that shift.

None of these are superficial. They map to product and team risks: maintainability, throughput, hiring, and long‑term viability.

When is the right time? Preconditions before you pull the trigger

Switching “because a new framework was released yesterday” isn’t a strategy. Tomi outlines the timing criteria:

• A stable product with enough revenue to cover the cost of a rewrite.
• A clear vision and feature freeze for the current state: what remains supported in the old system, what gets migrated, what belongs in the new framework.
• Adequate development resources: a rewrite is demanding and requires dedicated capacity.
• Company‑wide buy‑in: from developers to management. Like any big change, the longer you wait, the harder it gets.

These constraints anchor the decision in product reality and prevent an engineering‑only move that’s economically risky.

How to switch: research, reduce, decide

The core of the talk is a methodical funnel that starts with requirements and progressively narrows down the framework landscape.

1) Define requirements honestly

It matters a lot whether you are:

• just changing the look and feel (same app, different rendering),
• rewriting the whole front end, or
• keeping the same UI but switching the framework under the hood.

For TimeTac, specific components were non‑negotiable: grids, dialogs, calendars, and advanced data views—either built‑in or as high‑quality add‑ons. Also critical: developer support and tools (build, compilation, and developer experience), documentation quality (“easy to use, up‑to‑date, and understandable”), and total cost if third‑party libraries or components require licenses.

The knowledge factor matters, too. A new framework takes time to learn; existing team experience with a candidate can accelerate the kickoff.

2) Read the market—but don’t let trends decide for you

Tomi points to surveys like stateofjs.com that capture usage, sentiment, “like/hate” signals, tool ecosystems, and community size annually. A chart might show a “clear winner,” but his takeaway is caution: trends are useful map data, not the destination. They indicate where knowledge is moving and how the job market is shifting, yet lesser‑known frameworks can also work—with a higher risk of becoming outdated.

3) Measure hard data

Beyond sentiment, gather measurable signals:

• Community size and activity (e.g., GitHub statistics, version cycles)
• Who stands behind the project (backing yields future confidence)
• Who uses it (including bigger names)
• Availability of tutorials, videos, and blog posts
• Number of job postings (especially important for hiring as you scale)

TimeTac collected these inputs alongside pros/cons, opinions, and explicit checks for state management and performance.

4) Engineering discipline: a weighted spreadsheet

“Ultimately, we are engineers.” The team built a big spreadsheet, assigned weights to what mattered most to them, and evaluated candidates systematically. This makes priorities explicit and reduces bias from individual preferences.

The first pass enabled an early cut down to “the big three,” which many larger projects converge on anyway. Which ones exactly depends on context; the key is shrinking the choice set to something manageable.

5) Check fit with your stack and organization

After the coarse filter, look at fit:

• Integration into the current stack
• Need for additional infrastructure or tools
• Magnitude of the knowledge shift for developers (TimeTac moved from “XJS,” implying a substantial learning curve)
• Whether you’ll need external experts to kickstart the transition

Top priority: choose a framework the front‑end team actually wants to work with. TimeTac ran an internal survey of developer skills and experience across the finalists to ground this in facts.

6) Eliminate candidates with team input

The team eliminated one framework because employees had clearly more knowledge of the other two. Additionally, Angular showed “the most resistance in the community,” according to Tomi, due to major rewrites and a steeper learning curve. That left two candidates for the final round.

“In my opinion, it should never be just a top‑down decision. The developers should also have a voice.” TimeTac asked developers what they would rather work with—and trusted that signal.

7) The decision: React—with TypeScript

The winner was React. The team combined hard data, survey results, feedback, and discussion to reach a decision they could stand behind. TimeTac also chose to start the project on a TypeScript base. Tomi notes they hadn’t treated this as a first‑order criterion initially—but it should be.

Prototyping as reality check: a two‑day hackathon

Before switching fully, TimeTac organized a two‑day internal hackathon. The goal was simple: build a proof of concept for a feature. That let the team gauge how fast they could adopt React, how much working knowledge they already had, and whether the decision felt right in practice.

Tomi’s recommendation: run cycles of observation, evaluation, and reconsideration. If you hit technical limits—or even just feel the decision might be wrong—switch fast and without hard feelings. That mindset prevents sunk‑cost bias and preserves decision quality.

“Enjoy it”: deliberately extending the ecosystem

Once the team was confident, they curated the stack around React through quick evaluations and short PoCs. Tomi lists the chosen tools and libraries:

• State management: Redux
• Routing: React Router
• UI and base components: Material UI
• Date/time handling: Luxon
• For callback‑based code: RxJS
• Automated tests: Jest plus Testing Library
• Communication with the backend: TimeTac’s own open‑source project
• Desktop clients: Electron
• Calendar view: FullCalendar
• Automation: GitHub pipelines (running tests, linting, and deploying to production)

This wasn’t a theoretical shortlist; it emerged from developer‑to‑developer communication, quick trials, and prompt decisions.

Team culture as the multiplier: listen, decide, improve

Tomi closes by emphasizing team culture. “It’s important to always listen to your team. If something has to change, find a solution that works for everyone.” At TimeTac, every employee’s opinion matters. Weekly front‑end tea parties serve as a forum to discuss new libraries and tools, consider how to include them in the project, gather info, build proofs of concept, vote on changes, and incorporate them quickly.

These rituals keep the stack evolving deliberately—avoiding both stagnation and random tool churn.

A repeatable playbook: from dilemma to decision

The talk yields a clear, reproducible process. Each step comes straight from the session and together they form a robust playbook:

1. Clarify the problem: why switch at all? Support, maintainability, performance, or market realities.
2. Check timing: product stability, revenue to fund the rewrite, feature‑freeze scope, resources, buy‑in.
3. Gather requirements: re‑skin vs rewrite, component needs (grids, dialogs, calendars, advanced data views), documentation, tooling, cost.
4. Scan the market and trends: use surveys like stateofjs.com as a starting point, not a verdict.
5. Collect hard data: community, maintainers/backing, GitHub activity, version cycles, adoption by bigger names, learning resources, job postings.
6. Build a weighted evaluation matrix: spreadsheet with pros/cons, state‑management and performance considerations.
7. Reduce candidates early: down to a manageable set (“the big three” for many larger projects), then to two.
8. Check stack fit and learning curve: integration, infrastructure, knowledge shift, need for expert help.
9. Ask your team: survey skills and preferences; developers who will live in the framework must have a voice.
10. Decide with data—and call out platform choices like TypeScript explicitly.
11. Prototype: validate adoption speed and team fit via a hackathon or PoC.
12. Iterate: observe, evaluate, reconsider; be willing to change course without ego.
13. Compose the ecosystem: state, routing, UI kit, testing, automation, desktop, and specialized components—each validated with small PoCs.
14. Invest in culture: regular forums, shared criteria, voting, and fast, controlled incorporation of improvements.

Memorable insights from the session

• “The longer you wait, the harder it gets.” Big rewrites don’t get cheaper with time; delay raises risk and complexity.
• “It should never be just a top‑down decision.” Developer buy‑in is essential for a sustainable framework choice.
• Documentation is a must‑have. Easy, current, understandable docs cut learning time, reduce errors, and boost delivery.
• Prototypes beat assumptions. A two‑day hackathon can provide more certainty than weeks of debate.
• “Switch fast and without hard feelings” if limits appear. That mindset avoids getting stuck with a poor decision.

Practical application: From a fork in the road to a stable outcome

TimeTac faced the classic triad—stay, slowly migrate, or rebuild—and chose the rebuild. Along the way, they:

• grounded the need to switch (support, maintainability, performance, developer market),
• ensured timing made sense (product stability, revenue, resourcing, feature‑freeze, buy‑in),
• narrowed the field systematically (requirements, surveys, hard data, weighting),
• involved the team (skills survey, preference poll),
• made a data‑backed decision (React) and an important platform call (TypeScript),
• and de‑risked the move through prototypes, iteration, and a learning‑oriented tooling culture.

The resulting stack—Redux, React Router, Material UI, Luxon, RxJS, Jest + Testing Library, TimeTac’s own open‑source backend communication module, Electron, FullCalendar, and GitHub pipelines—wasn’t preordained; it was earned through small, fast experiments.

Conclusion: Decisions that last—because the team owns them

From DevJobs.at’s editorial seat, the standout quality of “How to pick the next Front End Framework” isn’t the naming of a single “winner,” but the discipline of the process. Tomi Močnik (TimeTac) demonstrates how to make a core technology choice without dogma, hype, or paralysis:

• research over gut feel,
• hard data plus the team’s voice,
• prototypes over PowerPoint,
• and the humility to adjust course.

What you get is a stack your team carries, that fits your product, and that leaves room to evolve. That’s what durable technology decisions feel like.

Key takeaways for engineering teams

• Don’t switch out of reflex—switch out of necessity, and only when product and organization can absorb the cost.
• Define requirements precisely. Components, documentation quality, developer tooling, and cost need to be explicit early.
• Let trends inform you, not decide for you.
• Measure hard data and use a weighted, transparent evaluation.
• Reduce the field early and test fit against your current stack and team knowledge.
• Give developers a real voice—skills survey, preferences, and shared voting.
• Validate with prototypes and iterate without ego.
• Compose your ecosystem deliberately—from state and routing to UI, testing, automation, and desktop.
• Build a culture that enables frequent, small, controlled improvements.

That’s how a thorny dilemma becomes a confident decision—and how that decision becomes a platform you can ship with, day after day, for years to come.

• 

  

  Are you using debugger and why not?

  Borislav Lazendic von TimeTac zeigt in seinem devjobs.at TechTalk die Vorteile von Xdebug und überprüft, ob an den üblichen Vorurteilen zu diesem Thema auch etwas dran ist.

  Watch now
• 

  

  TimeTac Connect, How we handle Integrations

  Anna Kastner von TimeTac erzählt in ihrem devjobs.at TechTalk darüber, wie das Devteam an die Challenges von Integrations herangegangen ist.

  Watch now
• 

  

  Challenges in mobile application development

  Ludwig Blaikner von TimeTac spricht in seinem devjobs.at TechTalk über den Weg, wie das Team ein Design Proposal zu einer funktionierenden Mobile Software gebaut hat.

  Watch now