|Page 1 of 2||[ 16 posts ]||Go to page 1, 2 Next|
I like the speed of frequent library updates, how soon bugs get fixed, how fast it gets faster.
I am not so happy about how fast new components are added to the library.
Recently, at a very late stage in the release of 3.6.0 there was an attempt to get TreeView into it. Fortunately, it was taken back. The component chosen from those in the Gallery was possibly the worst possible choice and the inclusion of such abomination in the library was averted, so it went back the the Gallery (poor Gallery).
Now I get a link to this video: www.youtube.com/watch?v=qO2xCmnY53g where Ryan introduces us to Y.Template.Micro, another template processor instead of Y.Handlebars which Ryan himself ported and now realizes it is too heavy on a client environment.
He ported BackboneJS about a year ago (or was it earlier?) and he later found out that Y.ModelList was too slow for large data sets, so he came up with Y.LazyModelList, which is mostly incompatible with Y.ModelList.
I don't need to mention how bad Y.Model is, I've been boring everyone within earshot about it and, if you haven't been one of the unlucky, you can read it here: http://satyam.github.com/WhyGalleryModel.html
What else will be brought into the library too early?
We already had DataTable, which had to be rewritten from scratch and, finally, we have something that works.
In yesterday's Open Hours we learned that there will be a YUIConf in November. I'm scared about what will come from it. Why? Because the bad version of DataTable was put together just to have something cool to announce in the YUI Conf of two years ago. Y.Model and all its associated stuff, along with Handlebars came for YUI Conf or thereabouts.
All failed components are plain ports, done on a rush, and all have been replaced or have better alternatives. DataTable was a trivial port from YUI2 DataTable, Model and ModelLists ports from Backbone and Handlebars is a port of the component or that name. DataTable has been replaced, Model is bad and should be replaced, ModelList has LazyModelList as an alternative, Handlebars is now about to have Y.Template.Micro as an alternative.
I'm old, I've already had all the excitement I care to have. Been there, done that. New component announcements at YUI Conf don't get me excited. I don't need that kind of excitement. I want dependable components, well designed, not trivial ports done on a rush.
Otherwise, the YUI Library will become a dumpster of failed ideas as the Gallery is becoming. In yesterday's Open Hours Dav Glass showed some cool stuff and also showed how the new Gallery 2.0 is going to look. What it really caught my attention is the little info box with the results of tests, coverage, latest update, activity and so on which, at least, lets you know if a component is for real instead of being dead-weight and how well and seriously it was developed. (check my components, none is lacking API docs, examples, tests and such). All these assisted by a wonderful new tool Dav is working on which is amazing (do see the recording: www.youtube.com/watch?v=-4ozoej5y08).
The Gallery is too cluttered. It is too hard to find a worthy component. No wonder when someone decided to get a TreeView into the main library they got the worst choice, there are too many and without any rating system, who is to know which one to choose? The same goes for outside developers. It is very hard to pick a component from the Gallery. I don't want the same to happen with the main library, see all the choices for templating: Y.Lang.sub, Y.substitute, Y.Handlebars, Y.Template.Micro.
In the same OH EricF brought some good news from the basic infrastructure area: Satyen has greatly improved the performance of Event, about 3x in some cases. Considering Events was one of the major problems causing the slowness of Attribute which affected almost everything (and caused alternative implementations such as AttributeLite used by Graphics, or AttributeCore which is used in base-core). This also justified all the callbacks in Y.Model, which is very NodeJS-ish but not very YUI-ish which might not be needed with faster events (Y.Model fires the events anyhow so the expense of setting them up and firing them is not spared, only the listening is saved which now might not be so critical).
Needless to say that I've already wiped out the old yuibuilder from my system in favor of Dav's Shifter. I've been using the new yuidocjs for quite long now. All these is great news.
What are we going to have to repent about in this YUI Conf? Can we take it easy on the announcements? Who are we trying to impress with such cool stuff? I must say, I'm not impressed.
Can we take it easy and take some more time to bring new components? Not all the 'cool' stuff out there is worth including. I expect the YUI Library to have some better measure of quality than coolness. Needless to say, I would like the Gallery to be cleaned up and not be the dumpster it is turning into.
I'm not a YUI developer or contributor, but I would like to share my experience porting gallery modules to Java for my project http://code.google.com/p/yuigwt/. I hope it contributes to this discussion.
I don't know if there is some quality module testing before including it to the gallery, but running a module without extra explicit configuration or resource loading should be required.
Then, IMHO it will always be normal to have "green" / experimental / outdated modules in the gallery.
Also, in other topic, I very like the idea of some YUI (non gallery) modules, like editor. First to introduce kind of abstract implementation, like editor-base and then, with time (I hope) introduce a concrete html editor like YUI 2 's rich text editor.
my two cents.
Oh no! Satyam has uncovered my dastardly scheme to destroy YUI. Now that my secret plan has been revealed, all the users I've bribed to pretend that they like the App Framework, Template.Micro, AutoComplete, History, and my other components will admit that they don't like them after all and were totally kidding!
Ryan: the first gallery module of you that I have ported to Java worked fine for me - very straight translation and no extra configuration required: http://cancerbero.vacau.com/yuigwt/?test=tokenInputPlugin1 keep the good work!
IMHO the gallery is also for proposals, experiments and incomplete works. Perhaps a more refined mechanism for the following tasks can help gallery users when choosing quality modules:
* user scoring
* module "degree", like A, B, C or alpha, beta, stable, etc
* better module information searching via web.
my two cents.
I would love a bit more features around categorizing gallery modules.
Even just a simple flag we can flip: "Proof of Concept", "RFC", "Release Candidate", "Production Ready".
As an example, I've pushed my Bootstrap modules out, but really don't think they're fit for public consumption yet.
That's the take away I'm having from this thread. Everything else happening with YUI is fine. Software gets better when it has more real world usage.
It's not painful to upgrade in most circumstances (DT 3.5 being one exception).
I would much prefer having real world usage get real world feedback that prompts better results. In short, keep up the good work.
Why are you taking this personally? I have not criticized all you've done wholesale, actually, I use several of the components you've developed and I'm happy about them. You probably forgot about it but months ago I kindly asked you if you didn't mind my borrowing code from your Y.View event handling in my MakeNode Gallery module. I don't think I'm getting that much respect from you.
This is not Satyam against Ryan (though it seems the opposite is true) but I think Y.Model is failed and I clearly documented that. If you feel attacked, that's up to you, it doesn't change the facts. I didn't insult you or make fun of you. I not only documented what is wrong about it but coded a replacement to show how it could be done better (see GalleryModel).
In my initial posting in this thread I also mentioned DataTable, the first incarnation of which I criticized then just as much and I am happy it has been fixed and in no way my critique was anything personal about Tilo. In fact, I would have been very happy if Tilo himself got it fixed after he gained experience (he was an intern then and recently arrived at that). I have no trouble with Tilo or with Gonzalo who did the TreeView gallery module that was about to be promoted to the main library.
My issue is with bad components, and yours are only part of it. Neither are all your components bad (quite the opposite), nor all the bad components are yours. So, it is not about you.
However, it was that part of your chat with EricF in the YUI Theater where you commented on the issues about Handlebars which prompted you to make a better alternative that made me think that there is a pattern here. And, once again, it is not about you, it is happening to you because you've been very active, but it is happening.
Whether it is a management issue, or perhaps it is that you all have too much pressure and can't find the time to discuss component design more in depth, or you are spread to wide in too many timezones or YUI Conf is coming and there is the perceived need to announce something or whatever it might be, I don't know.
That is why this thread is not (just) about Y.Model which is just one of the components affected. It is about something that is happening to you (and possibly to everyone else in the team) and not because of you. Something I don't want to see repeated.
So, as the heading asks, can we (you) take it easy?
No, I'm through taking it easy with you.
You're always quick to claim you're only providing constructive criticism, but you haven't yet learned the meaning of "constructive". Constructive criticism isn't just about what you say, it's about how you say it. I've stopped caring about the things you say because they're invariably couched in emotionally charged rants that I and other developers find insulting and demeaning.
You seem to perceive bugs, performance issues, and design choices with which you disagree as personal affronts, as if I and other YUI developers put them there maliciously for the sole purpose of ruining your day. If a component fails to meet your exact needs, you dub it a "failed component" and refuse to entertain the idea of any compromise that's less than 100% of what you personally want to use or more than 0% of what you personally don't want to use.
You claim that Model and ModelList are ports from Backbone. They aren't. They were inspired by Backbone, and are different in many ways. You claim that they were rushed into the library to get them out in time for YUIConf. They weren't -- they were neither rushed, nor did YUIConf occur anywhere near the date when they were released. You claim that they are failures. Interestingly, you're the only person who seems to feel that way, whereas we've heard from hundreds of people who seem to love them.
You claim that LazyModelList is "mostly incompatible with Y.ModelList". This is not true. The entire point of LazyModelList is that it *is* mostly compatible with Y.ModelList for many use cases.
Eric and I made public a casual discussion in which we spoke candidly about some of the shortcomings we saw with Y.Handlebars and how we can address them. Others thanked us for our transparency and applauded our ongoing efforts to learn from past mistakes and continue to make YUI better. You apparently took it as a sign that we were negligent and hasty in our decision to bring Handlebars into the library. I assure you we weren't -- we may have been wrong, but we were neither negligent nor hasty.
You seem to be under the impression that a perfect component can be developed in a vacuum, with no real-world usage or feedback. With AutoComplete, History, the App Framework, Handlebars, and other components -- and even yuilibrary.com itself -- our goal was to release something useful and then improve it rapidly based on feedback from real-world users, and that's exactly what we've done.
While I've often found your feedback useful when you've managed to avoid emotionally charged language and personal attacks -- and I'm grateful for that -- I have no use for your entitled, bitter, angry, hurtful rants about "failed components" and how you think we're ruining YUI.
Luckily for me, I no longer work for Yahoo!, so my contributions to YUI are now entirely voluntary. That means I don't have to put up with you if I don't want to.
I am sorry if I offended you which I obviously did, I apologize. Writing in English is not easy to me. 99% of my life does not run in English. I revise what I write 3 or 4 times and rewrite it over and over. What you might probably write in 5 minutes it takes a whole hour for me.
Though I wish it is no longer in the YUI Theater, you can probably watch my English in its natural state in the Open Hours presentation I gave about MakeNode. Though I prepared all the material well in advance, I sounded like a bumbling idiot. Same with written English, I cannot handle the subtleties of being 'strongly against' and 'aggressively against'. That is why I hardly participate in other channels but this forum, they don't allow me to review what I wrote. And even then, I don't get it right.
Just as I don't mean to sound like an idiot, I certainly don't mean to be aggressive, and when I feel I might have gone beyond the line, I apologize in advance since I can't even be sure whether I've actually been aggressive or how to fix it if I've been. I'm sure you could find several of such apologies in my messages in this forum. I am a grumpy old man, no question about it, but I don't mean to be insulting and if I've been, I sincerely apologize.
What I did with DataTable is what I call not constructive: I offered no good alternative, I just said what was wrong and left it at that. What I did with Y.Model or, more recently with TreeView is what I understand, as constructive, I spent hours working on that and documenting it. I cannot avoid insisting that Y.Model design is flawed and bringing it up when I have a chance.
And it is not all 100% or nothing with me. There are only two things I'm 100% against. One is using Attribute for record fields storage. Actually, my complaint about the original DataTable was that the Record stored its data as Attributes, which happens to be the same complaint I have about Y.Model. The other is that a TreeView cannot be made of TreeView and TreeLeaf classes as the TreeView candidate had. It has to be TreeView and TreeNode, as the YUI2 version has and every other version of TreeView out there does.
I can absolutely compromise on everything else, but those are very basic architectural decisions I cannot compromise because they don't work. If those are fixed, I don't mind about the rest. I can work around them, I can file enhancement requests or I can write plugins or extensions. A TreeView made of TreeView and TreeLeaf instances is a no go, a 100% no go. I still think that a model that cannot represent a table in an SAP database it is not complete, but it can be fixed. SAP does not exist in a vacuum, it is not some theoretical idea.
Is Y.Model good? Usage is no indication of that. Usage shows how badly an MVC framework was needed and since Y.Model provides the M in MVC, there is little else people can do.
Why do I care so much about it? DataTable is a final product, you can use it or not, you can use YUI2 DataTable or something else. Nothing depends on it. When I pointed that it was failed and nothing happened, I didn't mind that much, there were alternatives. Y.Model provides a very basic functionality and too many things depend on it, that's why I feel it is important. That's why I am strongly against it. If that felt like aggressively against it, or those involved in it, I am sorry, it is not what I meant.
This is mostly between Satyam and Ryan, I think, but I have something to add (after removing a longer post).
Every time Y.Model comes up there is a long winded rant.
When stating your opinion isn't appropriate (eg., https://github.com/yahoo/mojito/issues/259) and detracts from the discussion, you are being aggressive.
English skills have nothing to do with this.
State your opinion once. If people don't like it then drop it. This is YUI and *I* love Y.Model the way it is. I do not like your take on it. You wrote a weird half-ORM.
I don't want an ORM, I want Y.Model and we are intelligent and experienced enough to make this decision without being reminded in every thread where Y.Model is mentioned.
The rants because you personally don't like something are what make you aggressive. Your wording and English is not the cause.
The YUI Team is unable to do more than a very basic check on the modules offered on the Gallery. The YUI3 branch offers a guideline of how a module should be developed, and there are user guides to help you with that. If those guidelines are followed, everything works like a charm, CSS files get loaded just fine, everything works.
These guidelines were not clear from the start, it took a while for everything to work and to be widely documented and known. It is excusable in the oldest components, it is not so much in newer ones. However, the idea has always been to let the Gallery be as open as possible and impose as little restrictions on it as possible. A good idea might lie down there in a badly packaged component and you wouldn't want to miss it.
As you point out, there will always be green/experimental/outdated components. As @JShirley suggests, a flag that authors could voluntary mark would be great. Perhaps @Dav could add that and even send an invite to authors to update their entries. No reply would be a good signal that the component is no longer maintained.
For example, in a recent discussion about TreeView I wrote a sample of an idea I had about it. However, I didn't upload it to the Gallery because I didn't mean to make it 'production ready' and I'm tired of seeing so much trash in the Gallery, actually, I have a few unfinished modules there contributing to the noise. If I had the possibility of flagging it 'proof of concept', I would have uploaded the TreeView and mark those unfinished ones as well.
As for user scoring, a thread starts every once in a while about how we could work to make the Gallery better, for example, by inviting everyone (and specially their authors) on all available channels to review a particular set of related Gallery modules and come up with a plan to merge all the best parts of all those offerings into one. However, only an invitation by the YUI Team could seriously start such a gathering, and someone has to eventually settle any differences of opinion, and that's also the YUI Team. I am sure that once a design is agreed upon, there will be no lack of coders to work on it.
I would like to get a good TreeView out of the 4 or 5 offerings in the Gallery and several that are out there, like the YUI2 version or my 'proof of concept' that I didn't upload. Same with an Accordion, there are too many there. I would gladly work on such a 'Community Choice' module.
It would not only improve the Gallery by separating the grain from the chaff, it would make it easy to support those modules. Right now, each author has to take the burden of doing it, documenting it and, worst of all, supporting it. If any number of people in the community are acquainted with the chosen module, support would be easy as it would be spread amongst all. Usage experience improves. As it stands, Gallery modules can only be guaranteed to work in the particular environment and circumstance its author designed it for (and a good number of them not even that being, in the best of cases, 'proofs of concept').
|Page 1 of 2||[ 16 posts ]||Go to page 1, 2 Next|
|You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum