Skip to main content

primary-choice

Primary Conclusion​

In my opinion, Stack 3 – Next.js (React) + TypeScript backend (Express + Prisma) is the ideal option for our delivery team and the best long-term strategic choice for AI-era development and TwinSpires’ future advantage.

If TwinSpires isn’t ready to move forward with Stack 3, I think it would be great to align on the compromise (Stack 1)

Stack 1 is the pragmatic compromise between:

  • Our delivery speed (Node.js + TypeScript backend in our wheelhouse), and
  • TwinSpires' comfort (keeping Angular on the frontend, evolving from Java to TypeScript on the backend).

It lets us move quickly while giving TwinSpires a platform that feels familiar and sustainable to own.

Why Stack 1 works as a compromise

  • Keeps Angular for TwinSpires

    • Frontend teams can continue using the framework they know.
    • No forced Angular → React migration in the first phase.

  • Modernizes the backend without a full-stack revolution

    • Replaces Java/Spring Boot with a lighter Node/Express + TypeScript service layer.
    • TypeScript is conceptually close to Java (classes, interfaces, generics), making it easier for backend engineers to learn.

  • Single main web language

    • TypeScript across frontend and backend simplifies hiring, documentation, and cross-team collaboration.

  • Reasonable AI-era fit

    • TypeScript backend is well supported by modern AI tools.
    • Angular ecosystem is smaller than React, but still solid for AI-assisted development.

Thoughts from past projects (just musings, not prescriptive)​

Technology stack selection is rarely simple - in my past experience, it depends on many factors beyond pure technical merit. "It depends..." is often the honest answer, I think.

Team Experience and Reputation​

Based on what I've seen, use boring solutions when reputation is at stake.

  • I think standard stacks reduce risk and increase confidence from stakeholders.
  • Proven technologies provide more examples, documentation, and community support.
  • In my experience, as teams build credibility, there's more room to experiment with newer technologies.

Stack Viability Over Time​

I think long-term viability matters more than initial excitement.

  • New technologies / especially new npm libs are tempting, but in my experience, we should consider: will this stack / lib still be maintainable in 3-5 years AND HOW?
  • Will the ecosystem still be active?
  • I've found that framework and architecture dictate constraints - and we need to make sure those constraints align with long-term goals.

Critical check: Based on my previous experience, when choosing a stack and architecture, we need to verify that the architecture patterns "fit" the stack's capabilities. Many things don't stretch well, or stretch painfully. I think it's wise to be pessimistic here - if something feels forced, it probably is.

One New Technology at a Time​

Radio operators turn one knob at a time - I've found this principle applies to technology adoption too.

  • In my experience, if introducing something new to the project, don't introduce more than one new technology at once.
  • I think this reduces risk, makes debugging easier, and helps the team learn incrementally.
  • Example: If adopting React, keep the backend familiar. If adopting a new backend, keep the frontend familiar.

Team Experience vs. Deadlines​

  • I think experience with the stack directly determines delivery speed and quality.
  • In my experience, tight deadlines + unfamiliar stack = high risk of failure.
  • I believe boring solutions are top-tier—stable, proven technologies that teams know well.

Bus Factor and Knowledge Sharing​

In my experience, if only one person understands the project, that's a critical risk.

  • I think it's important to divide projects into stages that can be "touched" and understood, even if they don't deliver business value immediately.
  • Based on my previous experience, when introducing a new library or technology, we should present it clearly:
    • What problem are we solving?
    • What do we want to bring in?
    • Why do we want it?
    • What happens if we adopt it?

Avoid the "Magic Tool" Trap​

I've learned there's no single tool that solves all problems.

  • In my experience, every technology has trade-offs.
  • I think stack choices often determine time costs—some stacks are faster to develop in, others are faster to maintain.
  • Based on what I've seen, choose based on actual requirements, not the promise of solving everything.

The Bottom Line​

"It depends" is the honest answer to most stack questions - at least, that's been my experience.

  • I think we should consider team experience, deadlines, long-term viability, and how well architecture patterns fit the stack.
  • In my experience, be pessimistic about "stretching" patterns onto stacks - if it doesn't fit naturally, it will cause pain.
  • Based on what I've seen, prefer boring, proven solutions when reputation or deadlines are at stake.