A Shorter Letter

 

jrogelstad's picture
Enyo, Hewlett-PackardA couple years ago I learned of what is now one of my favorite quotes from one of our senior developers, Gil Moskowitz. I asked him why a particular development resulted in so much code and complexity. He referred to a quote from Blaise Pascal: "I would have written a shorter letter, but I did not have the time."
 
As many of you know, we've been hard at work on our new Mobile Web client. For much of this year the plan has been to base the client on Blossom, a fork of SproutCore, that we sponsored to evolve that framework to a mobile-ready platform. We debuted our new client running on Blossom at the OSBC and FluentJS conferences in May. A funny thing happened on the way to fame and fortune at those conferences. We discovered a better framework called Enyo.
 
Enyo 2.0 is a HTML5 framework based on Hewlett Packard's WebOS platform designed to work in any web browser environment including all popular desktop and mobile browsers. The first beta was released about a month after we started on our Blossom project. Having invested heavily in SproutCore and Blossom by May, we were more than a bit skeptical about yet another framework, but after seeing some impressive demos we thought it was at least worth a closer look. First what we found is Enyo is about 90% smaller than SproutCore. While SproutCore clocks in at around 300K lines of code and Blossom at 200K, Enyo is around 30K. As a result it is easier to learn and understand, so coding in it is a dream. It also comes with a set of widgets in its "Onyx" library that look great in all environments. Plus it's fast! Finally, Enyo is being actively developed and documented by a team of full time professionals. This was just too good to ignore, so we continued looking even closer.
 
One thing Enyo was missing was a strong data management layer, which is important to us because our application is so data intensive. For this we pulled in Backbone.js and a corollary project Backbone-Relational.js. These two libraries add up to about 1,500 lines of code and do more than the SproutCore datastore does in 6,800 lines of code. I was able to read the code and understand the APIs for these two projects in about a day.
 
Finally, we never quite got Blossom to work in all environments, such as phones. We found, however, that Enyo truly did work everywhere:  on phones, tablets, even the Kindle Fire! We decided to spend a couple more weeks coding in Enyo with Backbone and see where it would lead. In about a week I had re-written our entire model layer in Backbone and unbelievably didn't run into a single bug. In two weeks our new Enyo based application started to look very much like what we showed off in May.
 
The most important factor in our decision to change was usability. Because SproutCore and Blossom are so large and encumbered by so much indirection and a complicated run loop, the learning curve to use them is very steep and debugging is difficult. By comparison these other frameworks are a breeze to use. Enyo and Backbone are case studies of "Less is More," as neither are over burdened with features and code bloat like so many application frameworks in existence. So we decided to take a little more time and write a "shorter letter" with Enyo and Backbone. The outcome is a new client that is turning out to be a much simpler and more reliable product. We feel a few weeks of delay will pay huge dividends for our development team, customers and partners for years to come.
 
The Enyo team just released 2.0 final last week, and we are currently on target to release a beta of the new xTuple Mobile Web client running on xTuple 4.0 in the next few weeks as well ... so you all will be able to see and judge the results for yourselves. In the meantime I will leave you to ponder the relationship between features and the size and complexity of software with this excerpt from Douglas Crockford's "JavaScript the Good Parts":
 
"We see a lot of feature-driven product design in which the cost of features is not properly accounted. Features can have a negative value to consumers because they make the products more difficult to understand and use. We are finding that people like products that just work. It turns out that designs that just work are much harder to produce than designs that assemble long lists of features.
 
Features have a specification cost, a design cost, and a development cost. There is a testing cost and a reliability cost. The more features there are, the more likely one will develop problems or will interact badly with another. In software systems, there is a storage cost, which was becoming negligible, but in mobile applications is becoming significant again. There are ascending performance costs because Moore's Law doesn't apply to batteries.
 
Features have a documentation cost. Every feature adds pages to the manual, increasing training costs. Features that offer value to a minority of users impose a cost on all users. So, in designing products and programming languages, we want to get the core features 'the good parts' right because that is where we create most of the value.
 
We all find the good parts in the products that we use. We value simplicity, and when simplicity isn't offered to us, we make it ourselves. My microwave oven has tons of features, but the only ones I use are cook and the clock. And setting the clock is a struggle. We cope with the complexity of feature-driven design by finding and sticking with the good parts.
 
It would be nice if products and programming languages were designed to have only good parts." 
 
Amen.
A couple years ago I learned of what is now one of my favorite quotes from one of our senior developers here, Gil Moskowitz. I asked him why a particular development resulted in so much code and complexity. He referred to quote from Blaise Pascal: "I would have written a shorter letter, but I did not have the time." It may seem counter intuitive, but generally the more concise a body of code is, the better. Short code is generally less complex and therefore less prone to bugs and misuse.
 
For a large part of the year we've been working on our new mobile-web client based on Blossom which is a fork of SproutCore we sponsored to evolve that framework to a mobile-ready platform. We debuted our new client running on Blossom at the OSBC and FluentJS conferences in May. A funny thing happened on the way to fame and fortune. We discovered a better framework called Enyo.
 
Enyo 2.0 is an HTML5 framework based on Hewlett Packard's WebOS platform designed to work in any web browser environment including all popular desktop and mobile browsers. The first beta was release about a month after we started on our Blossom project. By May having invested heavily in SproutCore and Blossom, we were more than a bit skeptical at first, but after seeing some impressive demos, we thought it was at least worth a look. First what we found is Enyo is about 90% smaller than SproutCore. While SproutCore clocks in at around 300K lines of code and Blossom at 200K, Enyo is around 30K. As a result it is easier to learn and understand, so coding in it is a dream. It also comes with a set of widgets in its Onyx library that look great in all environments. Finally, Enyo is being actively developed and documented by a team of full time professionals. This was just too good to ignore.
 
One thing Enyo was missing was a strong data management layer, which is important to us because our application is so data intensive. For this we pulled in Backbone.js and a corollary project Backbone-Relational.js. These two libraries add up to about 1,500 lines of code and do more than the SproutCore datastore does at 6,800 lines of code. I was able to read and understood the APIs for these two projects in about a day.
 
Finally, we never quite got Blossom to work in all environments, such as phones. We found, however, that Enyo truly did work everywhere: in phones, tablets, even the Kindle Fire! This was too much to ignore, so we decided to spend a couple weeks coding in Enyo with Backbone and see where it would lead. In about a week I had re-written our entire model layer in Backbone and unbelievably didn't run into a single bug, and in two weeks the application started to look very much like what we showed off in May.
 
So we decided to take a little more time and write a shorter letter with Enyo and Backbone. The outcome is a client that is turning out to be a much simpler and more reliable product. We feel a few weeks of delay will pay huge dividends for our development team, customers and partners for years to come.
 
We are currently on target to release a beta of the new web-mobile client running on xTuple 4.0 in the next few weeks so you all will be able to see and judge the results for yourselves. In the meantime I will leave you with this excerpt from Douglas Crockford:
 
"We see a lot of feature-driven product design in which the cost of features is not properly accounted. Features
can have a negative value to consumers because they make the products more difficult to understand and use.
We are finding that people like products that just work. It turns out that designs that just work are much harder
to produce than designs that assemble long lists of features.
 
Features have a specification cost, a design cost, and a development cost. There is a testing cost and a
reliability cost. The more features there are, the more likely one will develop problems or will interact badly
with another. In software systems, there is a storage cost, which was becoming negligible, but in mobile
applications is becoming significant again. There are ascending performance costs because Moore's Law
doesn't apply to batteries.
 
Features have a documentation cost. Every feature adds pages to the manual, increasing training costs.
Features that offer value to a minority of users impose a cost on all users. So, in designing products and
programming languages, we want to get the core features 'the good parts' €”right because that is where we
create most of the value.
 
We all find the good parts in the products that we use. We value simplicity, and when simplicity isn't offered
to us, we make it ourselves. My microwave oven has tons of features, but the only ones I use are cook and the
clock. And setting the clock is a struggle. We cope with the complexity of feature-driven design by finding
and sticking with the good parts.
 
It would be nice if products and programming languages were designed to have only good parts." 
 
cleberjr's picture
Offline
Joined: 04/16/2012
platform support

One thing that does *not* please me is having Linux as a Tier-2 (lower priority support) platform.

http://enyojs.com/docs/platforms/

 
shackbarth's picture
Offline
Joined: 06/28/2012
Linux support

Hi Cleber, I'm Steve Hackbarth, one of the core developers on the enyo app here at xTuple. I've done all of my development for this product on Ubuntu 12.04, and I can vouch that I haven't run into any problems. And we're certainly not going to ship anything that doesn't run well on Linux, because that's one of our development platforms. I don't even think it'll be an issue; enyo runs great on Linux.

 
cleberjr's picture
Offline
Joined: 04/16/2012
It's comforting to hear that!

It's comforting to hear that! Keep up the amazing work!

 
kevinpschaaf's picture
Offline
Joined: 07/27/2012
Supported platforms

Hi Cleber, I'm Kevin Schaaf, the product manager on the Enyo framework. I understand your concern, so I want to clarify our support matrix a little bit. First, our goal is that Enyo works across ALL modern web platforms, period (which certainly includes Linux). However, "all" is a pretty huge problem space with a really long tail when you start permuting browsers with browser versions with devices with operating systems with operating system versions (any one of which can and often do result in strange browser quirks), so we thought Enyo developers would appreciate understanding how we prioritize our testing and issue resolution.

You should expect Enyo to work well across all Tier 1 and 2 platforms including Linux, with the main difference being the order and priority we give to QA testing and issue resolution, based largely on market relevance (for example we spend a lot of time on Android Gingerbread and ICS, and less on Honeycomb because there are far fewer devices out there). Right now we QA at least 17 different configurations at every release, but we do look at and fix any issues found on Tier 2 platforms, and we're working on automated and possibly crowdsourced testing to get better coverage across the long tail of other configurations. Not hating on Linux (or Blackberry or anyone else)! -Kevin

 
ned
ned's picture
Offline
Joined: 10/20/2008
I wouldn't read too much into

I wouldn't read too much into that. The multiplicity of Linux distros makes it perfectly understandable that a big company like HP would represent it this way - but we're confident that Linux will be well supported.

 
nmonday's picture
Offline
Joined: 03/19/2009
It must be scary to go

It must be scary to go through such a drastic change, after investing time and development efforts into a different solution. It really does sound like it will pay off in the long run though.

 
Joshua.K's picture
Offline
Joined: 03/05/2012
Is there a middle tier?

Is there a middle tier? I just discovered Enyo myself and have begun to play with it.

Traditionally, for browser based apps you have the database, and then some middle layer (JBoss and Struts, or Apache and Django) that serves up the javascript. Is that the case with Enyo, or have I not gotten the big picture yet?

 
jrogelstad's picture
Offline
Joined: 12/10/2008
We'll be talking more about

We'll be talking more about all this once we get the beta launched, but the short answer is yes there is a middle tier. It is made up of multiple components built using NodeJS including a service framework (node-xt), a router (node-router) and a datasource (soon to be renamed node-datasource). We've also built an ORM layer to handle object relational mapping and function dispatch calls on the database using plv8js for Postgres. You can see all the pieces here:

https://github.com/xtuple/

Please be advised, however, we are still in active development and will not be fielding questions on how it all works until we have a release.

Also note that current users of the Qt based version of xTuple will continue to be able to operate in version 4.0 without any of these new layers. These new components are strictly optional to support the web-mobile client.

 
MissySchmidt's picture
Online
Joined: 02/07/2012
Screenshot of EnyoJS.com
 
MissySchmidt's picture
Online
Joined: 02/07/2012
Enyo continues to share the love

Case study: xTuple finds Enyo "a dream"

Two months ago while attending O’Reilly’s Fluent JavaScript conference, we met the folks at xTuple who had a booth a few down from ours. Like many others we chatted with, they were hearing about Enyo for the first time and were somewhat skeptical, but pledged to give Enyo a closer look. Boy were we surprised when they let us know 6 weeks later that they had such quick success porting their mobile web client to Enyo that they were prepared to scuttle a half-year development effort using other frameworks and make the switch to Enyo! Take a look at this article from the xTuple blog where Director of Product Development John Rogelstad offers an insightful view into their reasons for making the switch.

http://blog.enyojs.com/post/28369861644/case-study-xtuple-finds-enyo-a-d...

 
szuke's picture
Offline
Joined: 12/01/2002
So will John be in Sunnyvale

So will John be in Sunnyvale this weekend?

 
MissySchmidt's picture
Online
Joined: 02/07/2012
Sunnyvale

@EnyoJS Hackathon 1st in SF Bay Area focused on Enyo-based applications. Saturday Aug 4 - who's going? http://enyohackathon.eventbrite.com/

 
jrogelstad's picture
Offline
Joined: 12/10/2008
I wish I could... but we've

I wish I could... but we've got to get this product to beta.

I've heard though that the Enyo Hackathon is completely sold out. Good sign.