eZ Community » Forums » eZ Publish 5 Platform » yui vs jquery
expandshrink

yui vs jquery

yui vs jquery

Wednesday 06 February 2013 10:04:50 pm - 31 replies

Would someone (Bertrand, Jérôme, etc) care to comment on javascript library plans for development of the new twig-based UI planned for later this year? I hear that YUI is going to be the choice and wondered if there was some justification for that the engineering team was willing to share. 

Wednesday 06 February 2013 10:17:00 pm

Hi Mark

Yes, YUI has been selected for all UI (new admin, editorial interface...). I'm not the best to comment this choice (Damien, if you read this...), but as far as I can understand YUI is way more powerful and clean than jQuery.

However, I don't think this prevents you to use jQuery for your own development.

Wednesday 06 February 2013 10:36:14 pm

There are a good post here, with some comments but some known guys here happy.gif Emoticon

http://dsheiko.com/weblog/yui3-vs-jquery

Thursday 07 February 2013 6:41:35 pm

Hi Mark,

Indeed, we (will) use YUI3 as a base for our frontend development. It's mainly because YUI3 provides a set of high quality and consistent JavaScript components for a great number of purposes from the ground (asynchronous loading, object model, events, MV* framework, ...) to a higher level (GUI Widgets, ...). The YUI documentation is very good and the YUI team also pays a lot of attention to not break BC which is a cool thing for us in terms of maintenance.

As mentioned by Jérôme, this does not prevent you from using the JavaScript framework of your choice in your project.

Cheers

Thursday 07 February 2013 9:54:48 pm

This graph speaks volumes: 

http://w3techs.com/technologies/history_overview/javascript_library

I can appreciate the technical arguments behind YUI, and have used it on several projects, but the current situation seems messy and continuing with YUI in the new admin seems like it will only continue it. When YUI was originally selected for eZ, jQuery was immature and less stable, but those concerns have long passed.

In 4.7, some of the eZ code is in YUI, but some is written in both YUI and jQuery (eZ Find), and some (eZIE) is jQuery-only. In fact, given the size of eZIE, there's a significant percentage of javascript in 4.7 that's already only in jQuery.

Given the popularity of jQuery, almost all eZ Market and community extensions use jQuery and jQuery UI since that's what most developers are familiar with. This leads to an inconsistent user experience since the appearance of the widgets is very different across the two frameworks. 

One of eZ's strengths is that the system can be easily modified and extended, and this is a point where YUI creates inconsistency. Having to understand two javascript frameworks to edit the stack just creates problems. So is it more sensible to convert the small volume of YUI code in the eZ Publish admin to jQuery, or try to force 97.5% of the world's javascript developers to learn a new framework in order to understand how eZ's admin works?

Thursday 07 February 2013 11:43:04 pm

Quote from Joe Kepley :

One of eZ's strengths is that the system can be easily modified and extended, and this is a point where YUI creates inconsistency. Having to understand two javascript frameworks to edit the stack just creates problems. So is it more sensible to convert the small volume of YUI code in the eZ Publish admin to jQuery, or try to force 97.5% of the world's javascript developers to learn a new framework in order to understand how eZ's admin works?

Well, we're trying to force php to learn ez publish framework for almost 10 years too happy.gif Emoticon. And i don't agree that admin is a small part in the ezpublish. i would say it's the biggest part... all the other things are extensions and the ones provided by ez systems normally uses yui. or let you choose yui or jquery as it goes for ezstarrating 

Let me add something to Damien and Jerome have spotted about bc. Looking at http://jquery.com/upgrade-guide/1.9/ i can understand that... 

So, ok, i see your point about the use of jquery. But widely used does not necessary mean better, as we all know...

Friday 08 February 2013 9:52:59 am

Quote from Joe Kepley :

This graph speaks volumes: 

http://w3techs.com/technologies/history_overview/javascript_library

I'm sorry but the popularity is not really an argument. For sure, the solution you choose has to be well known but taking the most popular because it's the most popular is a non-sense. Otherwise, we would have rewritten eZ Publish 5 in Java or in C...

I can appreciate the technical arguments behind YUI, and have used it on several projects, but the current situation seems messy and continuing with YUI in the new admin seems like it will only continue it. When YUI was originally selected for eZ, jQuery was immature and less stable, but those concerns have long passed.

In 4.7, some of the eZ code is in YUI, but some is written in both YUI and jQuery (eZ Find), and some (eZIE) is jQuery-only. In fact, given the size of eZIE, there's a significant percentage of javascript in 4.7 that's already only in jQuery.

that's exactly what we want to avoid this time! We choose YUI as the main framework for our development. How the legacy code is currently written has a very little influence because we are about to rewrite pretty much everything. And about eZIE, believe me, it's a maintenance nightmare, not because it's based on jQuery, but because it is based on various plugins that are more or less not maintained anymore...

Given the popularity of jQuery, almost all eZ Market and community extensions use jQuery and jQuery UI since that's what most developers are familiar with. This leads to an inconsistent user experience since the appearance of the widgets is very different across the two frameworks.

And what if jQuery UI does not provide the components you need ? You'll introduce yet another plugin that can be also very different in terms of skinning and look and feel. So choosing jQuery does not really solve this issue. But choosing a framework a bit more complete reduces it for sure. But again, for your project, you are free to choose any framework.

One of eZ's strengths is that the system can be easily modified and extended, and this is a point where YUI creates inconsistency. Having to understand two javascript frameworks to edit the stack just creates problems. So is it more sensible to convert the small volume of YUI code in the eZ Publish admin to jQuery, or try to force 97.5% of the world's javascript developers to learn a new framework in order to understand how eZ's admin works?

Extensibility is something provided by YUI by default. The framework is very well architectured, it allows to easily extend pretty much everything. And again, we won't convert anything from the legacy code, we are rewritting pretty much everything. But in any case, it stays JavaScript code, if you are a good "jQuery" developer, you'll be able to easily do your changes.

Friday 08 February 2013 10:10:26 am

@Joe a small historical note: there was a time, before we started bundling Yui/Jquery with eZ, in which we asked the community which Js framework to choose - at live developer events and iirc here on the forums as well.

The answer was almost always the same: 40% jquery, 40% yui, 20% something else.

That's why we decided to go for "mainly develop using Yui, but give devs the choice to use what they want".

As for ezie: it was started as a university-student-last-year-task project. And you can try to coach him as much as you want, it's always hard to get a student to follow all proper standards... blunk.gif Emoticon

Friday 08 February 2013 11:10:33 am

The decision to use YUI in backend was made many years ago, the difference in the up-coming 5.x Admin UI is that we exclusively use YUI, only thing we are considering instead of YUI are the up-and-coming mv* js frameworks popping up for backend guis. jQuery is not suitable for this kind of JS heavy UI, it's to simple and it/plugins breaks in every release.

Front-end is another story as long as it is JS light, if everyone wants to use jQuery on their websites we can consider using it there.

Friday 08 February 2013 12:09:20 pm

Since YUI3 will be a foundation for a new eZ Publish administration interface, I highly recommend all developers get familiar with YUI3. Good starting point can be a following book:

http://www.amazon.com/YUI-3-Cookbook-Cookbooks-OReilly/dp/1449304192

Tuesday 12 February 2013 12:50:39 am

This thread raises some interesting questions. The one that strikes me as most interesting is:

Do I understand this right: The plan is to build the new admin interface as a JS application? In other words, to have it be fundamentally different than the current scenario in which the admin interface is very much like a public-facing interface?

The reasons this is important, I'm sure you realize, are that the admin interface stands as (1) a benchmark of how capable and ready eZ Publish is, (2) as the most significant repository of expertise which is easily available to anyone with basic eZ Publish experience, and (3) as a very important location for customization.

Tuesday 12 February 2013 5:50:40 am

Hi folks, 

Very good discussions here! I totally follow Damien's explanation and must say that I like it and trust also his experience developing sites on eZ as a very solid input to the topic. Regarding how the JS landscape is moving, it seems to me vital to not have any constraint on what eZ Developers could use in the front end and this is the main thing. This is achieved!

Now about the back-end, while the volume/popularity is certainly a criteria, the criterias of Damien seems to me the more important ones: #extensibility in a clean way (I understand YUI3 is better here, especially reading @Carlos document), #BC - a major concern for eZ and one of the strength of the solution with no doubt, #maintainability because nobody want to kill innovation by having maintenance work hijacking all engineering resources (this situation happened at some points at eZ and was extremely painful). Listening to Damien and André, the next generation U.I. will also remove the inconsistency of the previous one by having only 1 js library. If YUI is better with these criterias, I am not sure Joe that we are making anything really hurting the developer experience but more the opposite.

@Doug yes we have considered using a more JS centric model (which cleary means the editorial interface would not any more be an example of how to make a 'website' with eZ BUT a perfect example of how to make a 'rich application' with eZ using the REST API. So there is pros and cons... and the editorial interface is anyway more of an application than a website, so using the REST API for that is not absurd at all! This follow somehow the evolution of the Web...

In any way it seems that we are going to an intermediate design where we of course give more to the JS client layer than before (how could we not...), try to use the REST API instead of the Public API as much as we can, but still rely heavily on the server side and the ez/symfony way to render content. This would still be a very good example blunk.gif Emoticon

And more importantly, extensibility is key and we are aware of that, we will try to make this new user interface better in that respect (which doesn't mean that everything should be extensible or customizable, just the right things)

Of course, this is my 'understanding' but I am way less technical than others, so feel free, especially Damien, to contradict me!

And the best to follow this, I think, will be to follow the Github repo and watch the progress happy.gif Emoticon 

Tuesday 12 February 2013 9:22:57 am

Hi Dough

Indeed, those questions are interesting and are a hot topic right now in the engineering team. Roland's answer covers most of it, let me just add some technical aspects.

Quote from Doug Plant :

Do I understand this right: The plan is to build the new admin interface as a JS application? In other words, to have it be fundamentally different than the current scenario in which the admin interface is very much like a public-facing interface?

Actually, the current plan is to adopt a balanced strategy between a full JavaScript application (often referenced as "single page app" ) and a more traditional approach (like the legacy admin) to get the best of the two worlds. We are currently working on a prototype that leverages the Y.App framework to build a progressively enhanced application. So, most of the rendering is still done server side and the JavaScript enhances it to give something much more handy to use. Y.App is a MVVM framework (quite inspired by the Backbone.js, some might know it) that gives a real structure to the application. For instance, this will avoid to spread the JavaScript code all over the templates. This will also allow us to unit test the JavaScript code

Quote from Doug Plant :

The reasons this is important, I'm sure you realize, are that the admin interface stands as (1) a benchmark of how capable and ready eZ Publish is, (2) as the most significant repository of expertise which is easily available to anyone with basic eZ Publish experience, and (3) as a very important location for customization.

Don't worry, we are fully aware of those 3 points happy.gif Emoticon The point 3 is the main reason to choose the progressive enhanced strategy over a full JavaScript application even if this gives some technical challenges at the same time. And by the way, this is not only a technical issue, we also have to pay attention to not limit the customization because of graphical or layout choices but this is Roland's job blunk.gif Emoticon

Quote from Roland Benedetti :

And the best to follow this, I think, will be to follow the Github repo and watch the progress

Unfortunately, the repository is not yet public, but I think we will open it soon!

Cheers

Modified on Tuesday 12 February 2013 9:25:17 am by Damien Pobel

Tuesday 12 February 2013 5:31:20 pm

I recently attended Sunshine PHP conference and specifically Dustin Whittle's talk on Symfony2 and emberjs this appears to be something that is gaining a great deal of attention as a framework and connects well to Symfony2. I was wondering if someone on the engineering side might have a comment about emberjs. In addition, in the past there were some versioning problems between custom extensions and the jquery version that was part of ezjscore extension. Maybe some comment or discussion about how these things might be avoided with eZ5 would be helpful.

Tuesday 12 February 2013 5:58:19 pm

I too recently attended the Sunshine PHP conference and went to the talk about emberjs. One key item to note about emberjs is that it makes use of jQuery, so that would now bring this discussion full circle. Personally I am a proponent of jQuery, not because I do not know JavaScript, but because I DO know JavaScript and it makes development faster.

The main issue I have here is the incomplete implementation of support for both. There have been many times on the frontend that eZ core files (i.e. edit mode) where the preferred library in ezjscore is jQuery however both YUI3 and jQuery must be used in order for the page to function. I have no issue making the admin interface by default use YUI3. However if the preferred library is set to jQuery globally (i.e. all site accesses), then this should be followed accordingly.

Wednesday 13 February 2013 5:28:26 pm

I hope to attend Sunshine PHP a year as well, good?
I don't know emberjs well, but looking at their examples it is very close to angularjs, with the difference being that emberjs uses string based templates while angular uses dom based templates. As some other dom based templates bases frameworks, angular allows two-way data binding between the dom and the controller, this saves a lot of code, and makes sure the controllers a thinner and easier to unit test.

Thursday 14 February 2013 9:20:29 am

Hi

Quote from Jon Henry :

I was wondering if someone on the engineering side might have a comment about emberjs.

Well, it's one of the (too) numerous client side JavaScript frameworks blunk.gif Emoticon but it's a good one AFAIK. It has a different approach than Backbone.js (or Y.App), it's perhaps more a true framework (ie gives a real structure to the application code) while Backbone.js or Y.App are perhaps more flexible on this. On the other side, it has a two way data binding support for your Models if you use the Handlebars template engine but for us that would probably mean to duplicate some view logic between the server side (twig) and the client side or do everything on the client which gives several kind of issues as well.
By the way, Symfony2 is very JavaScript framework agnostic, since it's really easy to write the code generating JSON and handling as a REST like API.

Quote from Jon Henry :

In addition, in the past there were some versioning problems between custom extensions and the jquery version that was part of ezjscore extension. Maybe some comment or discussion about how these things might be avoided with eZ5 would be helpful.

yes and the tendency for jQuery to break a lot of things between releases does not help for sure happy.gif Emoticon And fixing this issue is not easy, actually I don't know if we can somehow ? eZJSCore made quite easy to embed the ezsjcore version of jQuery (or YUI) but if extensions developers do not want to use it and embed their own version, what can we do ?

Quote from Michael O'Connor :

The main issue I have here is the incomplete implementation of support for both. There have been many times on the frontend that eZ core files (i.e. edit mode) where the preferred library in ezjscore is jQuery however both YUI3 and jQuery must be used in order for the page to function. I have no issue making the admin interface by default use YUI3. However if the preferred library is set to jQuery globally (i.e. all site accesses), then this should be followed accordingly.

that's true. But implementing everything to support two frameworks is a very big task. It makes sense for things used in the frontend and the admin like star rating for instance and it's usually not that big however for the rest, it's more complicated. But the current plans on front side editing *might* solve this issue in a different way.

Cheers

Friday 15 February 2013 3:45:00 pm

Damien - you mention that the admin will be progressively enhanced but at the same time heavily dependent on javascript. Will users who have disabled javascript (or who use assistive technologies, screen readers, etc) be able to create, edit, move and remove content? Maybe without the wysiwyg admin. but at least perform basic functions and navigate the admin?

This was possible in the admin interface until v4.5 which increased dependency on javascript which is now required to load subitems. 

Saturday 20 April 2013 5:08:32 pm

Recovering this post because we actually have an example of what have been told in previous comments. 

I just upgraded ezjscore from git, and because of that, it seems jquery 1.9.1 is been loaded. but, as their bc says, $.browser seems have to be removed from jquery 1.9.1. 

It happens that eztags uses jqmodal.js, an external plugin that uses $.browser to check for ie. 

https://github.com/ezsystems/eztags/blob/master/design/standard/javascript/jqmodal.js

As result, i'm actually having a javascript error editing content. 

So, maybe this is one of the reasons to not use jquery for new admin happy.gif Emoticon

Edit: Also it seems that "live" method has been removed... and it's used somewhere in eztags, and probably in other ez publish extensions... 

http://jquery.com/upgrade-guide/1.9/#live-removed

Modified on Saturday 20 April 2013 5:25:57 pm by Carlos Revillo

Monday 22 April 2013 2:26:46 pm

Carlos, it sounds like the jQuery Migrate plugin was not included with ezjscore, which really should have been added if the goal was to maintain BC. 1.9 does intentionally break some old bad habits, but Migrate restores those old behaviors for extensions that rely on them. 

jQuery has worked in 1.9 to resolve some of the issues that perhaps drove eZ to YUI in the first place, so I'd hate to fault them for cleaning those up.

Monday 22 April 2013 2:42:02 pm

 

Quote from Joe Kepley :

Carlos, it sounds like the jQuery Migrate plugin was not included with ezjscore, which really should have been added if the goal was to maintain BC. 1.9 does intentionally break some old bad habits, but Migrate restores those old behaviors for extensions that rely on them. 

Damien did include it recently to resolve an issue.

expandshrink

You must be logged in to post messages in this topic!

36 542 Users on board!

Forums menu

Proudly Developed with from