How do you select the right parts from a talk about how to select the right technology? Especially if you haven't spent a whole lot of time working with any of the development tools that are being compared? Perhaps you just listen to what resonates. And so I did at the All Girl Hack Night presentation on how to select a Javascript framework that's right for you, by Justin Lowery from Cerebral Ideas. Justin compared Angular JS, his team's favorite, with two other popular Javascript frameworks, Backbone and Ember. So while an experienced web developer might be nodding their head sagely at the criteria Justin gave (which I put at the bottom of the page), I just pondered how web development today is still oddly plagued by the same problems as when I did it in 1999.
When you just can't separate presentation from business layer...
Justin Lowery (the presenter).
Back in 1999, when we wrote cutting edge web applications with (ahem) CGI and Perl, separating business logic from presentation seemed a distant dream, which my team at the time quickly gave up on. We wrote spagetti code where HTML was generated in a deeply nested tangle of Perl's ifs and fors. It's 2013, and it sounds like HTML still can't be made completely independent of business logic. And some people say you might as well embrace that, and pick a Javascript framework that lets you hook up Javascript to backend-generated HTML easily. According to Justin, that's one of big advantages of AngularJS.
Those Javascript-hating backend developers
This will let backend developers generate chunks HTML without ever touching Javascript. In Justin's observation, backend developers hate Javascript, but are much more friendly with HTML. Why they hate Javascript more than HTML is anyone's guess. Perhaps it's because backend developers are used to "proper" object-oriented languages, whereas Javascript kind of has objects without actually being object-oriented. It has this strange prototype inheritance, which is not like the "classical" inheritance that backend developers are used to. But I have been a backend developer for a long time, and I'm not averse to Javascript: I've been learning it eagerly in recent months, and I'm fascinated by some of its features like closures.
Freeform HTML versus generating the whole page from Javascript
Then again, there exist Javascript frameworks that not just let, but force you separate presentation from business logic; it's another question if those solutions cause bigger problems than they solve. I am talking specifically about ExtJS. ExtJS expects all the data from the backend to be returned as JSON objects via service calls. I'm not sure you could make it accept custom HTML even if you tried. At least that would be very hard, and it would violate another of framework selection commandments: "Choose a framework designed by someone who thinks like you, otherwise you'd be fighting it all the way". It would be hard to stick any custom HTML into an ExtJS application, because ExtJS does not "hook" into your existing HTML: it generates it all from scratch, from Javascript alone. Some pople don't like that. I suspect our presenter didn't either, because he considers it an advantage if a framework lets you write free-form HTML, like Angular does.
This ties into our next criterion.
Page load time: the "no blank page" criterion
Left to right: All Girl Hack Night members Annine, Yim, Angelina, and Kate at the Angular JS presentation.
Allowing static HTML versus generating it all from Javascript is tied to another criterion: how fast the framework is. Mainly it means page loading time. Justin observed that a perception of loading time is not the same as the loading time itself. This criterion can also be summed up as "No blank page prior to JS parsing". If your application renders some HTML elements before it executes all the Javascript and populates fields with data, some HTML elements are already on the page even though some fields are initially blank. Even if loading the data into those fields takes 2 seconds, the user will still perceive this page as loading faster than a page that stays blank until it generates all the content, though that might take 1 second. In this case Angular obeys "no blank page" rule, whereas ExtJS -- you guessed it -- doesn't.
Opinionatedness: what does it mean?
The most mysterious criterion is probably "opinionatedness" of the framework. Perhaps you have to be an experienced front end developer to fully understand this concept, and I'm not. A Google search did not give me a crystal-clear understanding of what it means. Apparently, opinionated APIs are on the opposite end of a "scale" than REST APIs. Unlike REST, opinionated APIs don't treat URLs as resources. They are more like function calls that URLs: save(collection, key, value) versus http:///collection/{collection}/variable/{key} (this example is from an article Opinionated (RPC) APIs vs RESTful APIs). But from what I read, experts seemed to think that REST APIs are more intuitive than opinionated ones.
Clockwise from the left: Bridget, Patty, Ashley, Maryam, Simi, an IT guy from the company that hosts All Girl Hack Night; Justin Lowery (the presenter), Neelima, unidentified woman, Annine, and Yim.
Opinionatedness of the framework figures into its learning curve. Justin said that Angular JS becomes harder to learn as the API becomes less opinionated. This seemed counterintuitive to me. Why would it be harder to program using RESTful API than one that consists of commands? Googling more about it, I found that AngularJS is called opinionated because it forces you to give your application a certain structure. If so, that can influence the learning curve in two ways.
Again, let's take ExtJS as an example. If you are writing an application that resembles the "Hello World" tutorial, it's easy to use this framework. You follow the steps, and the widgets on the page magically materialize and get populated by the data from the backend. So the learning curve does not seem too steep. But then you find out that a real-world application does not match the confines of the tutorial, and its logic often does not conform to the structure the framework imposes on you. That's when the learning curve becomes steep, as you have to find various backdoors and workarounds around the framework's assumptions. From that perspective, I'd say ExtJS is very opinionated, and this can make it hard to write real-world applications. This framework gives you prefabricated houses instead of individual bricks. But if it gave you just the bricks, a beginner wouldn't know how to stack them into an architecturally sound house.
A meta lesson is that it may be hard to know what concepts are and are not too vague for an overview talk (assuming that overview talks are introductory in nature). All Girl Hack Night has developers from all walks of life, from device driver writers to front-end, and I don't know that many non-front-end developers are familiar with the concept of opinionatedness. I will have to keep that in mind when creating my own presentations.
What kind of philosophy / methodology does the framework use to solve problems?
- How is it architected?
- Is the framework authoritarian or egalitarian?
- Are all problems solved with Javascript?
- Are problems solved with a bigger, more aggressive API?
How does the framework solve common problems of development?
- Templating?
- Data binding?
- Routing?
- Bootstrapping?
- Data management?
How active are the creators in the community?
- Do they have an active forum with many users?
- Do they have stale pull requests or issues list?
- Are they active in the community?
HTML-centric philosophy
- HTML is intuitive for those that are non-Javascripters.
- Strong separation of concerns.
- Event binding is much easier.
- Backend devs that hate JS have limited exposure to it.
- Views are compatible with other frameworks, especially backend technologies.
Posts
