Meet Igaro App — Potentially the Web’s Finest SPA Framework

Some say that a web page should start with HTML, which is (or was) thought of as content, and that functionality should load on top of that (the filtering etc). Right or wrong? With so much content now generated dynamically, perhaps it’s time to revisit the way we do website design. Whichever way you lean, the back-end will largely be doing the same as it was ten years ago, but with a bit of partial serving and new protocol support. We’re still left with the problems of old: building and rendering a page made up of multiple fragments and trying not to hit a database server multiple times, which means careful thought on how data passes through the modules that represent them. And front-end wise, there’s the pain of trying to put a state into the /x/y/x URL being served, even though the user never loaded x and x/y to begin with.

I always thought there had to be a better way, but JavaScript, or the variety of devices that ran it, were never really up to shifting the work load from back-end to front-end. Bits yes, but not all of it.

And then they were.

Along came the frameworks; Backbone, still here, but diminished, Polymer, the next big thing — last year, the Angular explosion — now smoldering, and more recently Facebook’s React. I feel something is different with React, something that tells me the web is finally heading in the right direction. For one it isn’t using templates and thus has no need for two way data-binding.

The real architectural decision is not what templating language to use, or whether one should use TypeScript, or use a framework at all, it’s whether anything at all should be rendered server-side. A year ago it was mandatory, because the service that could make or break a product, GoogleBot, couldn’t handle a web app. But now it can, and so I must ask you the question you’ve asked yourself many times over the past several years: “Should I reload that part of the page via Ajax as a fragment, or regenerate that piece with front-end code (a.k.a. React), or modify the DOM structure with front-end code, or just reload the page?”

Then I will ask you one more question. It’s 2015. Why are we still asking this question?

A year earlier I embarked on the road to create a solution.

Introducing the Igaro App JavaScript Framework

Igaro App is a web app framework — a.k.a. an SPA (Single Page Application) framework — but one which takes a radical departure from the norms. For a start it uses no HTML and no MVC. It avoids using DOM query selector methods to try to improve performance, and therefore has no template engine. Instead it uses routes to build pages, and standard CSS for styling and layout.

It is written in pure JavaScript ES3/5/6 (no dependencies) and aims to outclass and outperform not at several things, but at everything. It’s purpose is to prove that by thinking outside the box it is possible to produce an architecturally brilliant foundation on which developers can code using the JavaScript they love, and not some abstracted, string parsed derivative.

Bold ideas and bold claims, and you should be skeptical. When you first view the website for Igaro App you may wonder where the center aligned “Apple like” sales page is, with its big fancy fonts and basic images. It’s inherently different because the website is the web app, which is also the downloadable repository. It’s functional and functioning, with all the documentation and widgets built right in.

Go ahead and clone it right now:

mkdir igaro 
git clone http://ift.tt/1OkLoDD igaro/git
npm install grunt-cli 
gem install compass 
cd igaro/git 
npm install 
grunt

Once cloned and running, the user has a development environment ready to go. Igaro compiles into two modes — debug and deploy and a web server for each can be found on ports 3006 and 3007 respectively. These will reload automatically as you work. Modifying “pages”, or routes, is as simple as editing the included route.* files . To see which route file maps to which page, or to inspect the source code for any page, just click the curly braces in the header section. A XHR widget allows for seamless JSON retrieval and creating new widgets to span over multiple pages can be done by inspecting any of the included instance.* files.

Continue reading %Meet Igaro App — Potentially the Web’s Finest SPA Framework%

by Andrew Charnley via SitePoint