Enyo vs. Other Frameworks

edited September 2012 in Enyo 2
As we talk with more developers, one question that often comes up is how we'd compare Enyo to other JavaScript frameworks out there. We're working on our own responses, but it would be amazingly helpful if any of you developers who've worked with frameworks like jQuery, jQuery Mobile, Zepto, Dojo, YUI, Ember, Backbone, Sencha Touch, etc, could post some thoughts about the strengths and weaknesses of Enyo compared to those.

We know we're not the ultimate framework for all uses on web and mobile. We also know that in a lot of cases, you can actually combine Enyo with other code bases to get the best of each world. It would be great to learn from your experience.

Thanks!

Comments

  • I've used jQuery on many projects. I'd say jQuery is useful for adding effects to your pages, and Enyo is useful for making actual apps.

    I actually combine Enyo with Prototype. Just got used to a lot of Prototype goodies from using Mojo on webOS and had to carry them over to working with Enyo.
  • In my personal opinion, comparing to Prototype, jQuery, and jQuery mobile, Enyo is the best. However , Enyo will work well if the developer master JavaScript, meanwhile the rest are closer to HTML, which is easier for people with HTML background. The best thing about Enyo is encapsulation ~ so if people coming from OOP background and having interest in design pattern, particular in DRY (Dont Repeat Yourself) concept, this is really interesting. jQuery is very rich in terms of "widgets", there are many widgets out there. jQuery mobile is too close to HTML, which make us to work harder to create more structured apps. I am not comfortable with the idea of putting HTML attributes to drive the layout as in jQuery mobile. Prototype is the first thing I know for JS framework, it gave me good impression of JS. The downside was it did not encourage for unobtrusiveness, which make complex apps hard to maintain. Google Closure is my second best option, but I don't have much experience on it, and at the moment not really well documented. Its strength is performance and well tested across Google apps. Senca Touch , in my short review, is the closest to Enyo, strong in OOP ~ but is it really free?
    Above is my personal opinion, and don't blame me for inaccuracy please
  • edited September 2012
    Ben, thanks for stating this threat !

    I added Enyo to this Wikipedia table "Comparison of JavaScript frameworks" http://en.wikipedia.org/wiki/Comparison_of_JavaScript_frameworks - but I know very little about other frameworks.
    I'd like to know who Enyo compares to other frameworks and which can be well combined with Enyo (what to use for what)?
    Should we enyo-fy other libs or better rebuild their functionality from the bottom?
    How to best build a true Model–View–Controller (MVC) architecture?
  • When asked to compare Enyo to other frameworks, I usually explain that Enyo a JS framework targeted at building web based applications, as opposed to enhancing existing web pages, and has a history of a Mobile and Tablet focus. And a key difference is that its about Components and Encapuslation, rather than a traditional MVC.

    I point out that other frameworks like Prototype and underscore.js are about enhancing the javascript language than creating widgets or setting up an application structure.

    jQuery is more about CSS selection and enhancing existing pages rather than defining application structure. jQuery fits well with progressive enhancement of an existing web page than structuring your application.

    I also mention that I've tried frameworks where you add attributes to existing HTML (jQuery Mobile and Mojo) and while jQuery mobile works well for a simple website, it doesnt structure well for a larger application. Having done traditional web development for a very long time, this "enhance HTML with attributes" model is easier to buy into, but ultimately I found it more natural building single page applications after I gave into letting JS build out all the HTML.

    Frameworks like Enyo and Sencha Touch are more about building an entire application. Then the next stage is usually to clarify that Enyo is different in that its not MVC. You design reusable components, rather than data models and views. Sencha Touch seems to be a less coherent framework - more of a collection of parts, but also does tend toward a more MVC approach.

    I've found that Enyo is also a great fit for how I naturally deconstruct a design for implementation. I'm often working with a team thats sketching, wire-framing and often visually designing an application, and the component model maps well to how I approach taking apart these specifications into an implementation. I see the repeated components, and break the parts into smaller components and then work out their data model for a visual representation. Then begin to work out the interfaces for communication between them.

    This also works very well for prototyping, where I can focus on iterating quickly on user interface options as those wires and designs change thru a number of design iterations. So rather than trying to first nail down a data model of everything based on visual designs, and then that data model then radically shifting as designs evolve and iterate, I can just focus on the UI components, and iterate on just the ones that change, without having to constantly rebuild the data model.

    I do combine Enyo with other libraries - I generally still use underscore.js. I was using MinPubSub but dropped it in favor of bubble/waterfall and Signals recently.


    One area I think Enyo is weak in is the data model portion - while Enyo can do it, I still tend to define some non-Enyo external Data model and interface to getting data in/out of it.

    And I find that Enyo not strong in managing navigation. For apps that only have a few different views you can wire them all up directly, but there doesnt seem to be a suggested model for how to manage navigation in an app with a large number of sections and states. I've built my own a couple times, but they feel fairly "bolted on" - managing a navigation history that builds state with each entry, and then having back button for example.
  • Thanks, Ryan. We know data modeling and navigation are weaknesses, but the good news is that work in ongoing on providing Enyo-like ways to handle them well. For example, routing based on URL is something we've done ad-hoc solutions for in API Tool and Gallery; we've an open bug to add it to the Enyo Sampler, and we're looking at ways to do it effectively using a real framework-level approach to add that.
  • At xTuple we use Enyo together with Backbone on the client, which works well for us.

    It's been important for us to have a model layer that's separable from the presentation layer and capable of running without the DOM, which Backbone can do. That's where we put our business logic, and the headless state is useful for unit testing (we use vows) and to drive a validation API for our other clients (like Drupal).

    Enyo and Backbone play together pretty well. Our Backbone layer is totally agnostic to the existence of Enyo, so information gets passed up with callbacks and with Enyo listeners on the Backbone model change events. The wiring is pretty easy. One downside, of course, is that we have to toggle in our heads between the conventions of the two frameworks, but javascript is javascript.
  • I agree you can combine Enyo easily with other solutions like Backbone. Its been great that Enyo generally "plays well with others", particularly for solutions that are not intimately tied to the DOM structure.

    I have had problems with some others, Adobe Edge Animate being a good example. Edge is an interesting tool for creating CSS and JS based animations, but integrating it with Enyo is difficult, though I think its is a failing of Edge more so than Enyo. I've used Edge for animations in an Enyo app - animations that may have traditionally been Flash or a video animation, and are now in HTML.

    Edge doesnt seem setup well to integrate as an Enyo component, so I'm having to load multiple, complex, animations at initial page load rather than as necessary. I'd be great so see what can be done to integrate things built with Edge into more of an Enyo component model, so they can be loaded async on demand - created and destroyed. So beyond what was attempted here: http://www.tricedesigns.com/2012/07/12/using-adobe-edge-animations-as-components/), but thats likely a task more so for Adobe. But something to consider as they invest seriously in these web tools in the Edge suite -- including PhoneGap.
  • Re: original question. If you have speed test and/or device compatibility data for enyo vs other frameworks, you should present that so developers have some "proof" of advantage of enyo. Also, tell us how enyo makes a developer's life easier than other frameworks.

    Also, what's your "killer" feature, something that no one else has - you need at least one. Some thoughts on what would be killer features (of course, require development on your end!):

    1. providing access to cloud storage that was used for synergy via enyo API's (wouldn't it be great to have access to same contacts, etc from desktops and mobile because enyo provide a way to add/delete/manage them from any device)

    2. developing a robust cloud storage API for enyo by partnering up with cloud storage/computing part of HP. enyo developers should get XX GB free storage.
  • edited September 2012
    Yes, I like this:
    2. developing a robust cloud storage API for enyo by partnering up with cloud storage/computing part of HP. enyo developers should get XX GB free storage.

    ... and thanks for all the good comments here ..
  • Hi Folks,

    I have been a developer for about 16 years commercially and have developed in almost every popular programming language and environment. I've been coding with JavaScript since it was called LiveScript - back in the day when you could use it to script 3D in your browser via VRML, nice to see we've made some progress ;-).

    I've done a good amount of development using jQuery Mobile and the raw HTML/JS approach to web-app development.

    Enyo currently takes a similar approach to Sencha Touch /ExtJS in that it uses purely code driven method to construct the UI as an object model. That's great and it gives the framework complete control over how the output to the UI is constructed and managed. Enyo is competing directly with Sencha Touch in this regard which is also mature and fast but targets mainly WebKit browser engines (so, not a very stable unique selling point for Enyo).

    I think it would be great if there was a way to add HTML markup (or at least an XML construct) as an (optional) way to declare/compose Enyo UI. As mentioned elsewhere this could be done in a similar style to jQuery Mobile/KendoUI etc. I recognise this is not a massively easy thing to retrofit.

    Why use HTML markup? Well, the first stumbling block even a seasoned JS developer will have is that they have to learn the Enyo API in some detail before they can get productive, with HTML you can demonstrate layouts declared in a readable and familiar form that's easy to grok. jQuery Mobile is easy to learn for that reason.

    Secondly, HTML (and XML) lends itself to tooling in IDE's (desktop and online), which speeds up experimenting with and building UI constructs.

    Thirdly, in the big bad world of app development, eventually you need a Designer (yep, 'fraid so). Designers have learned print and web layout, they know about branding, style and asthetics. They care not a jot for your object model. Visual Tooling provides them a way to work with an app design and apply creative elements. declarative markup (in the vein of HTML, XAML etc, with styling from CSS etc) is there for that reason (ok, HTML had a previous life for constructing 'documents' but it's flexible).

    As web-apps gets bigger and more complicated we need well thought out ways of separating concerns (UI/Layout from back-end code etc), ways of organizing projects for growth (big apps have 100K+ lines of code, not counting UI declarations) and build systems (to give you debug, staging and production output). We've already seen competing build/tooling components appearing everywhere to help streamline the workflow for big apps, just yesterday there was TypeScript (http://www.typescriptlang.org)

    Tooling and separated design concerns is all part of the growing maturity for web app development.

    On a lighter note, maybe I should just come and help if there's a job going :-)

    Cheers,
    Chris
  • Thanks for dropping in, it's much more verbose than Twitter ;)

    I'll get some other eyes looking at your post that may have a better answer for you. In the meantime, check out http://webosjobs.com :)
  • I think it would be great if there was a way to add HTML markup (or at least an XML construct) as an (optional) way to declare/compose Enyo UI.
    THIS. I've been toying with this idea for a while but haven't found the time to act on it. Something 'official' would obviously be preferred though.
  • "I think it would be great if there was a way to add HTML markup (or at least an XML construct) as an (optional) way to declare/compose Enyo UI."

    Yes, I think this is a great idea - I've also been thinking about how much easier it would be if we could just put in HTML markup/templates for certain things rather than doing all Javascript.
  • "I think it would be great if there was a way to add HTML markup (or at least an XML construct) as an (optional) way to declare/compose Enyo UI."
    In a sense, won't Ares take care of this? Because you can quickly/easily play around with layouts using that.
  • >In a sense, won't Ares take care of this?

    This is also what I expect from Ares2.
    As there is not yet a web hosted Ares2 available I have not really started with Enyo2 apps.
    I hope Ares2 will help beginners to better learn Enyo - and then later you might no longer need Ares2 ..
  • I'm not sure you'd want to try to wire behavior onto an HTML UI like you might do in jQuery. They're really two different approaches to the problem. Enyo controls expect to build their markup in a particular manner to ensure things function. There'd be some work to get event bubbling working as desired as well.

    It would be very possible to inject an Enyo control into a HTML template which seems like an interesting use case. For example, if you had a designer comfortable in HTML and CSS but wanted to add an Enyo-driven control in a particular spot (an interactive ad for example). I think it would a good candidate for progressive enhancement where you could deliver a standard control (e.g. simple image) and enhance it on load by rendering the Enyo control onto the same node.

    To illustrate, here's a quick fiddle that includes a jQuery plugin to render an Enyo control onto a node (or a set of nodes). Not sure you'd want to mix frameworks too much but I could see some viable scenarios, particularly with existing jQuery shops.

    http://jsfiddle.net/ryanjduffy/b58pA/2/
  • Yep, I see Ares is tackling the tooling side of UI design with Enyo, that's good and proves it's possible and likely to happen.

    The progressive enhancement approach is more or less what I'm getting at, the idea being you enhance existing control types, and only have unique constructs for controls specific to your framework.

    I suppose it's somewhat related to how committed you need to be to a specific platform, progress enhancement is reversible and you can quick port to an alternative framework - giving (perhaps) the illusion of choice and making the initial framework choice commitment easier.
  • does anyone have early access to famo.us? it looks great and i'm interested in what enyojs team would react to the emerge of this kind of framework. e.g. is it possible that enyojs simply switch to the famous rendering engine without breaking old codes (or minimal changes). it appears to me famo.us would be more like Sizzle so that other frameworks could built upon and taken advantages.
  • famo.us looks really interesting. It tries to solve different problems from Enyo and takes a very different approach to how layout of objects is controlled. I think it's quite possible to combine the two, but it's not something I've tried to do yet.
  • I was on a Sencha project. It is a bit overwhelming, the only way I was able to get up to speed was due to my familiarity with Enyo. I'd compare Enyo MVC to "Sencha lite". pretty similar in many aspects, but simpler/cleaner.
  • When we were trying to find the best framework to use for a business app about a year ago Enyo was a late entry and quickly became the favorite.

    Our main concern is getting our users the information they needed with great performance. Fancy graphics are nice but functionality, robustness, and ease of use win out.

    Enyo's performance on large data lists easily left everyone else in the dirt. Being able to avoid Out Of Memory crashes on iOS by destroying unused components when we wanted was also a great help.

    Our initial app was done quick and dirty but after a refactoring we now have a great understanding of how Enyo apps should be structured.

    Plan to continue to use Enyo even without all the MVC sugar.
  • My 2 cents: This is my second Enyo project, and Enyo is performing as amazingly well as I would expect. In this case, we needed something that could easily be componetized with a light touch on the DOM. There were requirements that required a secondary framework and we needed the two to interact well. Enyo's object abstraction and distance from the DOM made everything work very well without conflict. We recently moved to server side rendering and Enyo proved to be a champ again. We were able to wrap Enyo around the html instead of the usual process of data to html on the client. I can't think of many frameworks that would permit it as easily and robustly.

    We initially tried Angular, and Angular's tight control over the DOM made co-existence impossible. Enyo's strength is it's abstraction without causing performance issues.

    If I had to build an application with no dependencies beyond jQuery, and limited growth potential, I would re-consider Angular. Angular is so highly specialized and self-optimized that it provides incredible performance. That is the largest problem too. Angular does not play well with any other libraries and often stomps their code output in its own process.

    Backbone is great for Controllers and Models, but lacking in View functionality. Backbone requires something else to function as a strong View component. Enyo is a good candidate for this (See the TodoMVC project on this). With the release of 2.3, Backbone + Enyo probably becomes redundant.

    Enyo and Sencha look very much the same, but Sencha feels and acts very heavy. My experience with Sencha to date has not been pleasant.

    Ember seems like another flavor of the Kool-Aid used to make Angular so I haven't really been interested in trying it.

    With the power that comes with cloud computing, I think many web applications will begin moving pieces back to server side. Enyo is well positioned to support those kinds of web applications. If I can build a single page app, and limit heavy operations to an auto-scaling front-end server stack, then why do heavy operations on the client? ( http://www.nczonline.net/blog/2013/10/07/node-js-and-the-new-web-front-end/ )

    I would like to see a few things in Enyo to make it even more robust:

    1) Make it possible to load html objects into Enyo - Enyo functions in one direction --> create the component (like everyone else) on the DOM. I would like to be able to create the html and wrap it into an Enyo component

    2) Syntactic sugar over DOM interactions - Enyo provides a great deal of control over when and what renders into the DOM. I would like the ability to obfuscate some of that control with shorthand functions to automatically update the DOM and still correctly trigger observers and other functions. Something like setToDOM.

    3) Dependency management - Enyo is ridiculously small, but you can never be too small. I would like to easily configure what core components come down so I can use only what I need.

    4) Session and Local Storage kinds.
  • Great feedback, @dposin. Note: we have https://github.com/enyojs/enyo/blob/master/source/data/sources/localStorage.js as a placeholder for a LocalStorage-based data source, but it's not been implemented yet.
Sign In or Register to comment.