Full stack JavaScript technologies & trends to watch for in 2024

Full stack JavaScript development keeps storming the software & technology world and seems to take no break. In this article, I want to lay out my subjective assessment of trending technologies to keep an eye on in the coming months. These are mostly based on the community focus & sentiments, tech news, and client demand. Whether you are a seasoned developer seeking to refine your expertise or a newcomer eager to set a course in the dynamic field of web development, I hope you'll find this blog post inspiring and helpful in choosing the right tech stack.

React 19 on the way

There’s been almost two years since the last major React version was released.

In the meantime, a well-known “create-react-app”, the bootstrap tool for countless React-based projects with custom tech-stacks has been discontinued, and even React’s docs highly recommend picking one of the React-powered frameworks (instead of starting barebones and what they call essentially building your own framework later). There’s a pretty good justification for that in the docs, and I highly recommend reading through it:

Source

A next major version of React - 19 - has been announced recently. In my humble opinion, probably the biggest thing about this release is the introduction of the compiler, which is going to simplify and optimize a lot of details. For example: with the compiler’s assistance, there will be close to zero need to care about these cumbersome calls to memoization-oriented hooks, like useMemo or useCallback and functions like memo. Historically, these have been known for causing many headaches among developers and there are countless examples online of how these hooks have been used in a completely wrong way. Now, a compile step will take care of optimizations, hence no need to manually include these in the code. This is a win-win situation, when not only the code will be optimized automatically, but also will become much simpler to write and maintain in the long run. The introduction of the compiler follows the trends coming from competitors like Vue or Svelte.

The other big deals are Server Actions and Server Components. While these have been in use and available for quite some time now with React-based frameworks like Next.js or Remix, React 19 is pushing these features to the “stable” phase. So far they’ve only been available to web developers in sort of “canary” mode, along with things like client/server directives. In general, it seems like React is going towards an isomorphic style, blurring the lines between server and client codebase. It comes with a major shift in how developers can think about execution boundaries, as defining server-side actions and executing these on the client without a need to manually define clumsy API endpoints has never been so easy.

Test frameworks and tools

Testing has always been an essential part of the software development process. Recently, a handful of new & interesting solutions have been on the rise, and I want to point out the most important ones here.

Vitest

Vitest is a relatively new test runner originating from the same context as Vite, which is advertised as a next-generation tooling for the web, aiming to replace legacy tools like Webpack. The goal is to utilize the same project configuration in both, so that there’s no split between business logic code and test suites, as these usually go hand in hand. With modern web development in mind and well-known API compatibility, Vitest aims to become a de facto standard for testing both frontend and backend applications. It is equipped with a native TypeScript support, the API is compatible with well-known community standards (think: Jest), includes common features like coverage, snapshots, and mocking, and is just fast because of the parallel test execution. Developer Experience (DX) is a major driver for both Vite and Vitest and maintaining unit test suites with the latter is plain simple.

Playwright

While Vitest is primarily focused on unit testing, another framework designed for end-to-end testing is on a rise: Playwright. It’s a cross-platform and cross-language (JavaScript/Typescript, Python, Java, .NET) solution liked by developers and automated QA engineers. While Playwright is designed for web applications tests through browser automation, it also offers features that can be utilized for testing APIs. This capability stems from Playwright's ability to intercept, manipulate and validate HTTP requests and responses, which can be leveraged to test API endpoints directly, although in a way that's outside of its main focus on browser-based interactions. In my past projects, I’ve used playwright for that very purpose and maintained a few integration tests suites with services I was responsible for.

Testcontainers

Speaking of web services, these seldom exist on their own and usually depend on other components like databases, cache layers or queues. While testing integrations means spinning up a real infrastructure with all building blocks, how should one abstract away these in unit tests? Mocking/stubbing/faking is one way (e. g. by replacing an underlying database client with a “fake” implementation in unit tests), but could it be done better? Enter Testcontainers: a dead simple way to load a real instance of whatever service is needed in tests and throw it away afterwards. For example, if you need your unit tests for CRUD operations to assert they work as expected with a real Postgres instance (instead of mocking or stubbing), there’s a module for that. Using testcontainers is as easy as installing a package from npm, importing and configuring a given module and instantiating it in tests. Definitely worth trying for both existing and new projects!

Runtime environments - node.js alternatives

For a number of years, node.js has been the only “serious” JavaScript runtime environment for backend applications, outside of the browsers’ context. Besides historical turbulence (does anybody still remember the now discontinued io.js fork?) and tools like Nashorn for JVM there have been almost no recognizable alternatives.

Deno

It was around 2018 when Deno was announced (with version 1.0 released in 2020). With Deno, Ryan Dahl, the original developer of node.js, wanted to fix what he considered “broken” in node. While it is not a “drop-in” replacement for node.js (at least by default), it comes with several outstanding features and improvements:

• strict security and safe defaults: for example, access to filesystem and network must be explicitly granted by the developer.
• package management: forget about node_modules! Dahl pointed out introducing package.json as one of his 10 regrets and thus Deno is now following a different approach: URLs for dependency management powered by local cache (read more about this strategy here). It’s also worth mentioning that Deno uses a modern ES modules system by default.
• first-class TypeScript support: no need for additional tooling required for compilation, static typing is supported out of the box.

There are other differences between Deno and node.js, yet these are the main selling points for this new kid on the block. But is it the only competitor?

Bun

No! Bun is another runtime, advertised as a drop-in replacement for node.js (in contrast to Deno). Similarly, it supports TypeScript by default and solves the “module madness” compatibility problems internally, providing interoperability for both legacy CommonJS and modern ES modules without a need for special configuration. Well-known require(), import and dynamic imports (with top level await) are supported out of the box despite the module strategy used in the project.

According to benchmarks, it is also the fastest. Bun is one of my favorite most interesting projects out there. As the authors say in the documentation:

“Bun is more than a runtime. The long-term goal is to be a cohesive, infrastructural toolkit for building apps with JavaScript/TypeScript, including a package manager, transpiler, bundler, script runner, test runner, and more.”

It’s definitely worth keeping an eye on in 2024 - what could your projects gain with Bun?

LLRT by AWS

Finally, let me briefly mention one more thing: LLRT (Low Latency Runtime), the runtime designed specifically for AWS’s serverless applications. Advertised as capable of improving performance and lower costs at the same time, as of March 2024, it’s still an experiment. If your company heavily relies on AWS Lambda with JavaScript, this might be a tool worth keeping in mind for the coming months.

TypeScript

In the 2023 Stack Overflow Developer Survey, TypeScript once again ranked high in both “most popular” and “admired/desired” technologies. Virtually every fresh project supports static types out of the box, quite often by default.

At SoftwareMill, we use TypeScript for both frontend and backend full stack development. We value trust & confidence in code, as well as developer experience enabled by type safety.

In 2024, I still advocate for investing in TypeScript, same as I did over three years ago. With version 5.4 just released, the language keeps evolving and the adoption is higher day after day (despite it already being very high). Whether you are considering a completely new project, or migrating your legacy JavaScript codebase, keeping types under control is always a good choice. Rapid development & adoption of tools and libraries like tRPC is the best proof of that.

Summary

I hope this comprehensive guide will help to keep track of the most important full stack javascript trends in 2024. If you reached this far, I want to thank you for reading! If you enjoyed this post, consider sharing your thoughts!

Special thanks to Anna Zabłotna, Michał Matłoka, Krzysztof Ciesielski, Tomasz Krawczyk, and Jakub Antolak for their invaluable feedback and peer review of this blog post.