DEV Community

K
K

Posted on

3 Other Front-End Frameworks

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. 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, 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, its main selling point is that it leverages the standardized WebComponents 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.

Top comments (3)

Collapse
 
askanison4 profile image
Aaron

I think the biggest appeal to me for Angular over the others (and hopping onto smaller frameworks) isn't so much the framework itself, but the tooling.

Tooling in Typescript and VSCode have been standardizing really nicely around Angular in the last 6 months or so and it vastly improves the workflow. That's all bleeding over into React too, which is a major bonus. I'll not miss the days of writing JS in notepad and checking the console for problems...

Collapse
 
kayis profile image
K

Personally I don't give much about static typing, but if you care: Cycle.js is written in TypeScript. Its creator is even a main contributer to RxJS, which is the core of Angular2.

Collapse
 
askanison4 profile image
Aaron

ooh? I'll give it a look :)