December 26, 2017
The Rise of Compiled Languages on the Frontend
The Triumph of Gradually Typed Languages
Every successful engineering organization goes through the same evolution:
- Build an app in a dynamically typed scripting language so engineers can iterate quickly
- Hire more engineers
- Realize that those engineers can’t iterate quickly anymore because there’s no documentation
- Realize that those engineers are breaking the app because they don’t know what else a change might affect (you probably regret not listening to your coworker when she said “write more tests!” in all of your code reviews)
- Are built to interoperate with untyped legacy code
- Are easy for existing engineers to learn (you just have to learn a few annotations, not a whole new language and runtime)
- Give you free documentation
- Cut down on the number of unit tests engineers write
- Approach the same safety guarantees that statically typed languages give you
- Make engineers (especially engineers new to the team) productive again
On the frontend, 2018 will be the year that TypeScript and Flow live or die. The biggest issue facing both ecosystems is missing & outdated typings for third party packages. Either a critical mass of programmers will start to ship their libraries with TypeScript or Flow types (one can be compiled to the other), or the languages will suffer slow deaths as users leave because the third party typing story is broken.
2018 Prediction: TypeScript’s growth will continue accelerating.
The Rise of Code Generation
Code generation tools are becoming a standard step in the frontend programmer’s toolchain. In the last year people have built lots and lots of tools to make APIs typesafe; you can compile JSON, JSON-Schema, and GraphQL to any language, GraphQL to TypeScript, Thrift to TypeScript, JSON-Schema to TypeScript, TypeScript to JSON-Schema, JSON-Schema to Flow, Flow to JSON-Schema, and Swagger to Flow.
The jury is still out on whether GraphQL will beat REST. GraphQL certainly solves a lot of problems (documentation, schemas, versioning, performance over unreliable networks), but there is a big barrier to adoption (it is not plug and play for many use cases, legacy clients still use REST, many apps have magical REST endpoints that do more than read/write a single resource, etc.). If GraphQL loses, then either JSON-Schema or Thrift will emerge as the winning documentation and schema layer.
I like GraphQL, and I also believe there are lighter weight solutions for the problems it solves: HTTP2’s multiplexing and push for performance, Swagger or JSON-Schema for documentation and schemas, API-level versioning. Switching to GraphQL can be expensive and you don’t have to swap out the whole API layer to get these benefits, which is why I believe we’ll see more teams choose lighter weight solutions over GraphQL.
2018 Prediction: GraphQL adoption will slow, and JSON-Schema adoption will grow.
React will Win, Redux will Lose
React has won the small-medium webapp market, and will continue to make its way into the market for large apps. The intuition is that for most apps, simple and predictable performance and mental models are more important than a framework that covers every possible use case out of the box. Sure, I can build an Angular4/Rx app with IndexedDB storage using CRDTs to sync data between users, but then again I could use React and
fetch to do most of that with a fraction of the cognitive overhead.
While Redux’s simplicity solves a lot of problems, the amount of work it takes to understand it, use it, and make it typesafe is a barrier for many. It sounds nice in theory (“Duh, my state is a fold over a stream of actions”), but in practice, I think programmers will continue to use traditional, Object Oriented models (ala. Backbone/Angular/Ember). Most engineers are not functional programmers, and OO models offer an easier way to think about encapsulation. That said, the flood of Redux variants and plugins will continue and Redux will continue to be popular among the FP crowd.
2018 Prediction: React will continue to dominate other frameworks, and Redux adoption will slow in favor of something that looks more like traditional Object Oriented Models.
JSX will Win
JSX-like syntax is supported by TypeScript, Vue, Elm, and Angular, and even Rust and Scala. I could write a whole essay about why I think JSX succeeded, but to sum it up in a sentence: familiar abstractions win, and typesafe abstractions doubly so.
2018 Prediction: JSX will become the standard templating language for HTML.
Webpack will Continue to be the De Facto Winner for Packaging
Other bundlers will come and go, but Webpack will remain the standard through 2018. People are tired of setting up build pipelines, and Webpack works pretty well for the majority of use cases.
2018 Prediction: Webpack will win.
Code Analysis Tools will Become More Sophisticated
3 + 4, you know this will always evaluate to
7; if you can make that substitution before you run your code, you can shave down the time it takes for your app to start up and improve how fast it runs. This kind of optimization is a no-brainer for most teams.
Rollup and Webpack tree-shake your code, reducing bundle size and improving parsing performance.
ESLint, TSLint, and Prettier make linting and automatic code formatting accessible in a way that Closure Linter, CodePainter, JSBeautifier, JSFMT didn’t. Prettier in particular is a zero-config formatter, and it has some clever rules that codify the unspoken style conventions we use when writing code.
2018 Prediction: Prepack and Prettier will become standard tools in every project.
And of course Uber will keep open sourcing everything (maybe then people will stop calling them a taxi company).
Have thoughts? Send me an email.