3 Other Front-End Frameworks
Tags: javascript, framework
Published: 2017-05-21 14:12:49

---
title: 3 Other Front-End Frameworks
published: true
description: Ember.js Cycle.js Skate.js
tags: javascript, framework
---

This week I wanted to write about 3 frameworks, that I personally found rather interesting for different reasons. They aren't hyped or big players, but have a solid community and unique things that make them worth a try.

## Ember.js

For me, the first framework that comes to mind is [Ember.js](https://emberjs.com/). It's a bit older than most JS frameworks. It was first called SporutCore 2.0, but renamed. So if we count the SproutCore inception as the starting point for __Ember.js__, we get 2010. 

Despite its age, it reinvented itself many times in these years. Starting as a _MVC_ framework, it included _components_ based approaches and _server side rendering_.

I haven't used it for years now, but, back in the days, it was a bit more concept heavy than React, for example. It also went mostly with _convention over configuration_, which makes experienced developerss really fast, but can confuse starters.

What I really liked about __Ember.js__ is its stability and the fact, that its developers have years of experience with updating and migration, so they get innovation into the framework when needed, but don't forget about existing codebases. 

## Cycle.js

The next is [Cycle.js](https://cycle.js.org/), which is a bit younger, starting development in 2014. It's build around the idea that everything is an observable stream. Streams of clicks, streams of DOM-nodes, streams of JSON elements.

Apps are structured by data-flow-components, which are functions that take observables, modify them in some way and returned the modified observables. For example, you could get a stream of JSON objects via WebSockets and transform it into a stream of DOM-elements that gets merged into the DOM to visualize the JSON data.

__Cycle.js__ has very few concepts. Functions and observables. You can model everything with this. And since observables offer many was to control data-flow in time and space, it gives you very fine grained control about what happens when and how in your app. 

Sadly, observables have a steep learning curve. You only have to learn one concept, but this will take much rethinking.

## Skate.js

Then there is [Skate.js](https://github.com/skatejs/skatejs), its main selling point is that it leverages the standardized [WebComponents](https://developer.mozilla.org/en-US/docs/Web/Web_Components) APIs integrated in browsers. Shadow DOM, Custom Elements, etc. As with most browser APIs, this one is rather clunky and not too nice to use, so _Skake.js_ tries to be a tiny wrapper around it. 

A pitch for _Skate.js_ is basically a pitch for WebComponents. The use of this APIs enables a standard way to integrate components made with it into existing applications. _Skate.js_ components interface with pretty much any other JS framework that can render DOM elements.

## Conclusion?

Most developers use one of the big players, like React or Angular, but I think it's worth to look into other approaches to solving the problem that front-end development is.

Should I go for the newest thing or does something like __Ember.js__ give me more safety?

Should I do what everyone preaches or is __Cycle.js__ a much saner way to control your data-flow?

Should I do framework specific components or do I want to integrate with the whole Web with the help of __Skate.js__?

It is also nice to know, that these frameworks aren't owned by a big corporation like Facebook or Google.