Tag Archives: RiotJS

Exploring RiotJS – Route 66

via Exploring Riot.js – Route 66 (Takeaway).

Hey! Nice to see you for the last blog post of the series « Exploring Riot.js » (I promise, it’s the last one, this time).
Last time, we’ve been how Riot.js routing API works with a simple Hello World example. But while coding this example, I felt that it was a bit short. Probably not enough to give an idea of our to start a « real » project with the Riot.js routing feature. So, I’ve carried on a bit more my investigations…

Exploring RiotJS – En route to

via Exploring Riot.js – En route to….

Welcome back to our Riot.js exploration!

This time, we explore the routing feature which is the last main feature of Riot.js and will enable you to code amazing apps. This post will also conclude our series « Exploring Riot.js » (don’t be too sad…).

Exploring RiotJS – Get your hands dirty

via Exploring Riot.js – Get your hands dirty.

The last post was presenting some features of Riot.js, a UI micro-library.

Part 1: Exploring RiotJS – Event-driven app

via Exploring Riot.js – Event-driven app (Step1).

In the previous post, we were presenting the traditional “Hello World” example using Riot.js a UI micro-library that enables to create custom tags “à la React” (if you wish something to compare). Not only does Riot.js support custom tags but also nice features such as eventing and routing (see this post). Riot.js team point of view is: custom tags + events + router = backbone to build cool nice applications. So, let’s explore a bit more Riot.js features…

Part 2: Exploring RiotJS – Event-driven app

via Exploring Riot.js – Event-driven app (Step2).

In the Step 1 of our “Exploring Riot.js – Event-driven app”, we’ve seen an amazing app that presented the same data in different forms: a table and a chart.

Exploring RiotJS – Introduction

via Exploring Riot.js – Introduction.

Riot.js presents itself as « React-like user interface micro-library ».
Personally, I would qualify it as a user interface micro-library whose philosophy is « webcomponents ». At first sight, what comes in mind is a lightweight Polymer-like library plus some nice goodies.

Why and How You Should Write Progressively Enhanced Idempotent (Stateless) JavaScript

via You Should Use Progressively Enhanced Stateless Javascript | Fusionbox.

As a user, there’s nothing that annoys me more than a non-working website; As a developer, I notice that most of these bugs happen in JavaScript.

Writing JavaScript is the trickiest part when programming a website. Your back-end is always going to run in the same environment, in a reproducible manner. However, with client side code, this could be run by many different platforms (browsers) which all have a different behavior. In addition to this, browsers come in different versions which implement different sets of features.

If you want to support the 2 latest versions of each browser, you end up having to test and write code for no less than 12 environments! (2 versions of Firefox, Chrome, Internet Explorer, Safari, Opera, Android’s Browser.) Add to this people who are still using very very old Android phones, and you get a deadly cocktail for front-end engineers.

As a preamble, this blog post talks about simple JavaScript interactions which improve the user experience. We’re not talking about single page applications. In these cases, you should use React.js if you want to go mainstream, Riot.js if you’re worried about size, or Mercury if you like modularity.

In this blog post, we’ll be talking about simple JavaScript interactions, very often written only using jQuery.

Also, this blog post assumes that you have basic knowledge of html, web accessibility and javascript.