Transpiling Front-End Components

An introduction to framework agnostic front-end development

Photo by Amy Humphries on Unsplash.

Compilation is a generic term in programming for transforming one unit of code, written in one language to another language. Transpilation, however, instead refers to the specific act of moving one unit of code written in one language to another language with a similar level of abstraction.

In the following article, we’ll be outlining use cases for transpiling code between frameworks in the front-end. We’ll also explore how we can use a simple framework transpiler, with examples.

Developing Flexibility

In enterprise development, there are many factors to consider before adopting new technology. As technology adoption is no small feat, these choices are among the most difficult a tech organization can make. Let’s examine two scenarios commonly faced when adopting new technology.

Technology Lock-In

Imagine the following scenario: it’s 2010 and you’re in the decision room at your office. It’s been a year-long debate, and the technology stakeholders have finally decided on the new framework to rebuild your ageing front-end. They’ve decided on Backbone — you’re excited because it’s cutting edge. There is so much potential compared to your legacy stack. The peel-off will consume the majority of your engineering team’s bandwidth for the next six months. It will require a substantial amount of training and some new hires who are already familiar with the new technology.

Now, fast forward 5 years (a.k.a two lifetimes in the JavaScript ecosystem). The debate is now between React, Vue or the host of alternatives you’re betting on with your adoption.

This scenario illustrates a common problem in the enterprise world known as technology lock-in. Changing technology could mean rebuilding huge stacks and training hundreds of developers. The financial commitment, investment of time, as well as resources is why many fear technology pivots and only execute them when necessary.

Organizational Flexibility

In our second scenario, I’ll give an example from SSENSE:

We were early adopters of Vue — like 1.0 early. We’ve recently passed the first anniversary of completely switching our front-end to the framework. Vue is currently on version 2.8 and has only recently gained popularity in North America.

Since the framework is so new, Vue developers are tricky to find. As a result, we usually hire developers with other front-end experience and train them instead.

Additionally, we have a whole facet of our organization which builds native applications for internal use. Since Vue didn’t have a mobile option when we wrote the internal software, we decided to use React Native. This means that although both web and mobile tech teams share the same design resources and art direction, and that each platform has many design similarities, we are left to maintain two code bases that are almost identical when rendered.

Transpiling Problems into Solutions

To restate the above, the situation we’re currently facing is our siloed dev teams using two frameworks to produce a similar front-end interface. Our proposed solution to this issue (and by proxy, the other issue we’ve mentioned) is — you guessed it — component transpilation.

The goal of our solution is to build a shared component library that is framework agnostic. We will write components in one language that once exported, can be consumed by any app. This library is still a work in progress, however I can share a small piece of the puzzle and, the most important piece in regards to transpilation: Flip!

Flip was built to solve the problem in scenario #2 above. At its core, Flip is a wrapper around a few custom Babel ASTs built by the Vue team. Together, with many modifications, they transpile React components to Vue components.

An example file structure that could use Flip would look something like this:

- src
    - app
    - pages
    - components
 - configs
 - node_modules
    - @company/components
    - @ssense/flip

We can run flip /node_modules/componentsand import them in the application from the dist directory that Flip will generate. This could work in the main application or from inside a node module that uses Flip to export both React and Vue components.

Feel free to clone Flip and run the tests to see this transpiler in action. I’ve also pushed a small example of the above interaction to GitHub.

Next Steps

Above I mentioned how component transpiling ties into a larger pattern — this pattern is referred to as micro front-ends.

Micro Front-Ends

If you’re familiar with micro-service architecture, micro front-ends follow a similar pattern. Here is a brief overview: with micro front-ends, we break up our user interface based on some predetermined factor. While factors vary, here are the most common:

• Scalability: so you don’t render your entire website when 80% of traffic is hitting one page
• Organizational: to give teams sole ownership of their services and UI
• Practicality: so your organization can incrementally invest in technology

If you’re interested in this pattern, you can find some cool tools here and here, a list of resources here, and check out some interesting readings here and here. The pattern is new, so you can also follow the ThoughtWorks technology-radar report on it here.

P.S. — we’ve released Flip as an open source tool on GitHub —try it out on your next project! You can find it at www.github.com/ssense/flip

Editorial reviews by Deanna Chow, Liela Touré & Prateek Sanyal

Want to work with us? Click here to see all open positions at SSENSE!