Discussion of Next Gen Topics

Hi folks, you can use this thread (or create your own in general) to discuss our plans for Next Generation (as described here: http://blog.enyojs.com/post/142040626224/a-new-era
«1

Comments

  • @RoySutton @theryanjduffy , would you guys like to start the discussion :wink: so we know in which direction you are planning to go? We can offer feedback on that...
  • We are pretty early in our exploration. We recognize that a lot has changed in the web application space since Enyo first started so we're taking time now to survey the landscape and leverage the collective experience from the JS community at large.

    From our perspective, we want to maintain what we feel are the 'good parts' of Enyo -- strong developer ergonomics, native-quality UIs, a comprehensive feature set, and a free, open-source platform -- but we see a need to improve performance (particularly on resource-constrained platforms like the TV) and improve overall application and framework quality by simplifying things.

    We can't say at this point what is going to change only that we are open to change. If there are aspects of other frameworks that you feel are 'easier', are better performing, are more (or less!) flexible, we'd like to hear about it.

    Some thought starters ...

    What is your favorite feature of Enyo? Most frustrating feature?

    What features of Enyo make it easy to write applications? Which features make it feel more complicated than it should be?

    If you could build a franken-framework from everything out there, what would it be?

    image

  • My two pence worth.

    Favorite feature - Elegance of Object Model, making it easy to create new UI controls, from others, with no real effort.

    Most frustrating feature - Fitable Rows / Columns, never seem to do quite what I want with out some fudging, to make the height / width what I required.

    Feature that makes it easy - Simple to install system, slightly harder with 2.7, as now need npm, in the past it was just unzip the bootplate and go.

    Feature that makes it more complicated - The new enyo tool has appalling help information on how to use it, when I first tried it using enyo -?, gave no useful information on how to start a project with a template, or what any of the other options are for do.

    Not really used any other frameworks, plumbed in a bit of jquery in 2.5, but that was just for one control I needed.
  • Favorite feature(s) / Feature(s) that makes it easy
    1. Component based nature that is organized into different groups (published, events, handlers, components).
    2. Ability to organize and reuse code.
    3. Love bindings and event handling system - so much easier to use than with Angular2

    Most frustrating feature(s) / Feature(s) that makes it more complicated
    1. Documentation, specifically on intermediate-advanced topics on certain things. For example, in-depth details on RelationalModel and examples of how to use it.
    2. Examples on how to implement common tasks, e.g., login forms, oAuth authentication, etc
    3. Creating forms (or anything with lots of UI components) is time consuming and verbose. Writing components in JS that represents HTML/DOM is painful and hard to debug. A HTML template type system (like in Angular/Angular2) or even something pseudoHTMLish (like in ReactJS) would be extremely useful.

    Requested features
    1. Some kind of HTML template system (ala Angular2 or ReactJS), preserving enyo bindings.
    2. Support for WebWorkers to improve performance.
    3. More examples / tutorials on various aspects of how to use framework in real life situations and/or how to use various components with other existing frameworks.

    Franken-frameworks
    1. I'd probably use enyo Models/Collections (plus a few UI controls) with Angular2 (unless enyo 3 has HTML templates, then I'd use that), mainly because Angular2 has a lot of support and modules being developed for it (integration with meteor, firebase, auth0, etc). Plus, they will be making it easier to use WebWorkers.

    My opinion is that you should make one part/module of Enyo a "must-have feature" and show how it can be integrated with existing popular frameworks. My sense is that the models/relationalmodel piece (with a bit of additional work on integrating with existing databases) could be that piece. I would imagine LG TV apps need to store data locally/remotely and do some syncing with LG phone apps? :)
  • The ability to use Ares (interface builder), along with PhoneGap build service, was really nice.

    The ability to target many devices, both desktop and mobile, was sublime.

    The object oriented nature of "kinds" along with nested components is exactly how most people want to wrap their minds around a problem when designing apps.

    The inherent structure of providing a "best in class" solution for everything on the client... right down to minimizing and compressing our JS and CSS into single files. It was the most complete and compelling solution available.

    If you are going to leave 2.7 as the last build of Enyo 2... please devote some time to making all the pieces play nice with it including Ares.
  • One more thing - I like that there is no "tag twiddling." Not having to muck with HTML makes perfect sense. It is a lot like Seaside in that way. Very few frameworks work like this but it's awesome.
  • Thanks for the great feedback!
  • Any thoughts/updates from the LG side? :)

    I have to verbalize the opposite opinion from @recurve. I like the ability to use HTML. I've made some complex pages with Enyo and writing the HTML page in Javascript is a lot more verbose than had I written it in HTML. It is much harder to figure out the layout reading the Javascript, just seems much more verbose than HTML, and less portable as well. I'm sure it adds some overhead in processing also.
  • We are in a creative destruction phase right now. We are trying and discarding a number of ideas. We will be blogging about some of our findings and ideas soon! We just want to nail down a lot of the big pieces so that it doesn't appear as chaotic on the outside as it is on the inside. ;)
  • edited June 2016
    First, I've used several versions of Enyo ranging from 1 to 2.5. I have not used 2.7 mostly because I disagree with the new approach to controls and its need to require .

    In my opinion, this new var Panel = require('moonstone/Panel'); is a major step backwards from earlier versions of Enyo, and should be scrapped as a bad idea immediately. I apologize to the people who pushed this forward, but it was (in my opinion) a bad investment: it adds a layer of complexity by forcing the user to do something that the framework should handle itself. And while I understand the reasoning, and also see other frameworks (like SAPUI5) do something similar, this must be - in my opinion - one of the worst decisions made to Enyo, and it is the single most important reason why I don't want to update to 2.7.

    The remainder of this post will be less negative, and I celebrate the work put into Enyo (and even version 2.7). I simply disagree with the decision, and would scrap it if I could. Anyway...

    I agree with TimE that the simplicity of installing Enyo is a big pro (and I too preferred simply unpacking a zip-file rather than the reliance on npm, but that's not a major issue).

    One of the best things about Enyo is, that it allows me as a programmer to express my own way of working rather than forcing me into specific paradigms. The fact that I can use MVC if I want to but don't have to rely on it is a great example.

    Another thing, that has been mentioned already, is the component or object based organisation that really allows for both reusability and expandability. This form of compartmentalization is one of Enyo's greatest strengths (although I expect that some people don't like that these components often combine the view and controller properties; I on the other hand really like that about them).

    I agree with recurve (and disagree with psarin) on the dissociation with the DOM (HTML). I find HTML templates much more tedious and harder to read than Enyo's JavaScript abstraction; even though I'm experienced in HTML, and have worked on and with HTML templates (not in Angular though, so I do not base my opinion on that particular library). I find that creating complex layouts using Enyo's component system is much faster, cleaner, and easier to read than trying to achieve the same using HTML-templates would. Well, we all have our personal taste, and maybe Enyo can cater to psarin's while staying true to itself.

    In summary:
    Favorite feature: component based organization that are both reusable, and easy to organize. As a personal preference I like that the view and controller properties a single object on screen can be combined within a single component/kind.

    Most frustrating feature (Enyo 2.5 and earlier): I always have to check how to best create and destroy components dynamically at run-time. I don't use this often, but sometimes lazy component creation is very valuable, and it would be great to better support this out of the box.

    Feature that makes it more complicated (Enyo 2.7): having to require dependencies manually. This is something I feel the framework should handle itself.
  • Since my post here a few days ago, I've talked with a number of people to get a pulse on the "pure javascript" issue. For me, it's no different than an ORM. If we can trust an object-relational-mapper to make our SQL for us, why not trust something like Enyo or JO to make our HTML? It guarantees there will be no dangling tags, no malformed HTML. It helps ensure no memory leaks from left-over event listeners. It helps ensure speed of rendering as you don't have to parse an incoming HTML file. It's also faster because we can precisely control when and how we render instead of doing it too many times.

    What I learned from others over these few days is the following:

    1) Many people can't make the mental leap. It's too frightening to both trust javascript for making your app and to have it make your HTML. It unnerves them... so they go for frameworks with less magic.

    2) Some people try to make large views in JS with Enyo instead of braking them into smaller reusable components. That's of course one of the cool benefits, breaking things up and reusing them... but many of us are so used to writing these large pages that it becomes hard.

    3) There are many components and workflows like "fitable" that just take a while to learn. Instead of learning how Enyo would like to do things... for many of us our first inclination is to try to do what we've always done... and that just doesn't work for Enyo. You need a different mindset. You're designing an app, not a web site.

    When you watch videos like this one from Kevin about components for web apps, you can't help but get excited:


    But then, we wonder, what happened? You know presentations like that exist at a major conference but then why don't more developers jump on and use Enyo / Ares?

    For starters, that video doesn't even state Enyo in the title nor in the description, it is very generic. Only 4k people have viewed it since 2012. Most people have never even seen it!

    Even if I learned about Enyo and googled for videos, I'd never EVER find that one... which is a shame, because it's one of the best.

    Also, Enyo is one piece of the puzzle. Almost all of us want to serve an app with persistence and we have to craft the rest of it. There are no "soup to nuts" tutorials on how to do that but with something like "MEAN" there is at least a roadmap of how to get it done. There are blog posts out there that hold your hand - get your authentication up and signups persisting in a DB. (MEAN - Mongo Express Angular Node)

    We have Roy's book, which is good, gets the core concepts of Enyo which is a big deal - but there is no clear way how to write the complete stack... like maybe Enyo (client layer), Node (server layer), Express (rest API layer), Bookshelf (ORM layer), Passport (authentication).

    It's not good enough to be the "best" in something. To gain mindshare there needs to be a way for the "average Joe Developer" to spend a weekend and make something real.

  • Any updates from the enyo team on this? :)
  • Some news coming soon ... (today?) ... I'll let Roy do the honors :)
  • Enyo news would make for a great start to the weekend! :)
  • There's an adage that says "no news is good news." And, there is good news. We've been
    hard at work on our successor to Enyo. Our plans for more openess during this phase were
    subsumed by our work. We do plan to open our repositories once we have things in place
    that will be needed by the community (you do like docs, don't you?).

    So, in the spirit of getting the discussion going, here's a little preview of what comprises
    the next-gen framework:

    After much deliberation we decided to build on top of the excellent work done on the React
    ui library. Most of the work that we're doing is figuring out how to build a complete
    framework on top of the React ecosystem that simplifies the day-to-day concerns of
    developers of different skill levels and implementing our Moonstone theme. We are also
    focusing on making a more modular library that can be consumed more easily in mixed projects.

    We would like to begin talking about the individual decisions that we made along the way and
    about things we discovered during the implementation process. Stay tuned for that.
  • Thank for this interesting outlook !
    I'm anyhow looking into React these days.
  • I guess this makes sense when you consider an LGSVL job posting I saw for a "Software Engineer (Enyo JavaScript Framework)" and in it there was React as a desired skill.
    I guess I better start looking into React so I can be up to speed.
    Thanks for the update Roy and thanks to all the Enyo team for all that you do.
  • That's interesting and great! If there's a way to preserve the "enyo-ness" in building off of React, that would be super-excellent! Enyo does things in an easier way than React in many cases and hopefully this can be preserved. Looking forward to hearing more!
  • @psarin - We are trying to strike a balance between maintaining the existing developer ergonomics of Enyo to make existing users' skills portable while keeping in line with idiomatic React to allow component reuse and knowledge transfer. I think we're in a pretty good place so far but I'll be interested in the communities feedback once we're ready to share.

  • This leaves me with a question.

    I have some apps on 2.5.x which are behaving just fine, I tried getting my head around 2.7 but the change was too big to get everything converted.

    Now should I wait for 3 and skip 2.7?
    I'm not assuming that 3 is more like 2.5 its just the learning curve I'm debating.
  • If your app is working well on 2.5, I wouldn't recommend updating to 2.7 unless you run into bugs that are fixed there. You'd likely gain some performance benefits from the improved bundler but I understand it takes some effort to make that conversion.

    If you're coming from a primarily Enyo app background, there will be a moderate learning curve because the underlying architecture is changing but the result is a simpler architecture. However, since it's based on the React library instead of a custom core like Enyo 2, there is a larger community you can tap into to ease the curve.
  • If we are wanting to get a jump start on where Enyo will be headed, should we just start learning React in general or is there a lib or add-on that we should be looking at that will be similar to how Enyo will infuse/interact with React?
  • @theryanjduffy that was the answer I was looking for.

    I have not performance issues, or bug fixed in 2.7 so I would save myself from 2 learning curves.

    Will the principle of kinds and inheritance etc still work the same ?
  • edited November 2016
  • Any news guys?
  • Good question! We are definitely on the cusp of having something interesting to share. Internally, we are getting close to our Beta release, which is the milestone we set for ourselves to begin our public release work. We have a basic docs system in place (one of the big blockers for our public release), but it needs some polish. We have a sampler. There's still a lot more to do. I'll try to hop on and give an update once we release our beta.
  • edited December 2016
    Thanks @RoySutton, I know I can't wait to see the greatness that you guys have in the works.
  • Hi Guys,

    I noticed WebOS 3.5 got announced, does this bring any goodies to the EnyoJS community ?
Sign In or Register to comment.