Faster Compilation

Write your apps even faster with more efficient compilation!

It’s no secret that Scala compilation isn’t the fastest process. But when writing frontend applications making small edits and getting immediate feedback is a crucial part of the process. Slinky 0.5.0 includes many steps towards making these edit-compile-reload cycles even faster with new optimizations for both what happens inside the Scala compiler as well as significant reductions in the amount of code that needs to be reloaded.

One of the biggest changes with Slinky 0.5.0 is a complete rewrite of the Reader/Writer system, which is used to persist state across versions of your application in development mode. Previously, this system was implemented with a fork of Jon Pretty’s excellent Magnolia library, which makes it super easy to implement automatic derivation of typeclasses, in Slinky’s case the Reader and Writer ones.

Slide from my Scala Days 2018 talk where I explained how Reader/Writers enable hot reloading

However in order to handle different types of systems, Magnolia performs the actual construction of typeclasses at runtime, which results in lots of type information needing to be bundled with your application that makes your app update more slowly in development mode. With Slinky 0.5.0, this is replaced by a custom derivation implementation that performs all typeclass construction at compile-time and is able to cache even more instances. All together, this results in up to 2x drops in development bundle size and up to 30% drops in compilation time (especially in component heavy apps).

Smaller Bundles

The work to pack applications into smaller bundles never ends!

Along with improvements to make the development process easier, Slinky 0.5.0 also comes with many optimizations to make the final production bundle loaded by your users even smaller!

When writing components, Slinky provides a tag API for constructing HTML trees that is similar to JSX. However, this API adds a layer of logic on top of just constructing the raw elements, since we must retrieve the list of attributes, convert them into a JavaScript object that can be passed to React, and then actually calling React.createElement . So a piece of code like this:

div(id := "my-div")("hello!")

Ends up expanding into a lot of allocations to construct the attribute key-value pairs, then adding on children, converting the list of pairs into an object, and finally constructing the element. This isn’t ideal both for performance and bundle size reasons, since now there’s a large amount of logic that needs to be emitted for every element constructed. With Slinky 0.5.0, the logic for constructing these tag trees is now more aggressively inlined, resulting in code that looks a lot closer to what a JSX compiler would emit. So the code above gets compiled into JS that looks something like this.

var props = {};

props["id"] = "my-div";

React.createElement("div", props, "hello!")

These optimizations put together result in ~5–10% production bundle size reductions.

Scala 2.13 Support

There are so many awesome features coming in Scala 2.13!

The next major version of Scala, 2.13, is coming up soon with a much simpler rewritten collections library and many compiler performance improvements. Slinky 0.5.0 comes with support for Scala 2.13.0-M4, making it the first React-for-Scala library to support a prerelease of Scala. So when Scala 2.13.0 finally comes out, you can expect Slinky to support it right away!

New @react Macro Implementation

Trying to make sense of error messages before Slinky 0.5.0

Slinky comes with the @react macro annotation, which makes it easy to eliminate boilerplate when writing React components. Before, this annotation was implemented with Scalameta, but with the deprecation of Scalameta annotations and the announcement of official built-in support for Macro Paradise in Scala 2.13, Slinky 0.5.0 has switched to using Macro Paradise for the implementation of this annotation.

Along with support for future versions of Scala, this change also drastically improves error messages that occur in the body of an annotated component. With Scalameta, these error messages were nearly impossible to decipher with line numbers gone and the entire body collapsed onto a single line.

Huh? Where’s the error exactly?

With Macro Paradise, this experience is a lot better with error messages that match what you would get without using the annotation. So the error above now looks like this:

Now that’s a lot easier to understand!

With the new macro annotation implementation also comes refined support for Slinky in IntelliJ IDEA through the library extensions feature. If you enable extensions following the Slinky installation docs, you’ll automatically get code-completion support for all Slinky features including the @react annotation!

Get Started Today!

Slinky 0.5.0 is out on Maven Central today! Check out the CHANGELOG to see changes you might have to make if upgrading from an older version of Slinky.

If you’re getting started with Slinky for the first time, you can use Create React (Native/VR) Scala App to get started with a full application with build tools already configured and ready to go!

sbt new shadaj/create-react-scala-app.g8 # For React on the web

sbt new shadaj/create-react-native-scala-app.g8 # For React Native

sbt new shadaj/create-react-vr-scala-app.g8 # For React VR/360

Make sure to check out the Slinky documentation and GitHub repo too!

And be sure to join the Gitter community to stay up to date on the latest developments in Slinky and chat with other Slinky devs!