YUIConf 2012: Two awesome days

By YUI TeamNovember 29th, 2012

In the past few years I had no opportunity to attend or give a talk at YUIConf. I’m currently living in Europe, so traveling to Santa Clara is not so easy. For that reason, all these years the only experience I had with YUIConf was to watch the videos on YUI Theater. I really enjoyed them, but I always wanted to be there in person to talk with people from the YUI team and other Yahoo! Engineers, to share with them my experience, to give them some feedback and just to learn from the source about the future of YUI. This year, thanks to my company, Liferay, I had this opportunity.

Initially, I didn’t know what to expect — all the impressions I had were only from the videos. In general, it turned to be an invaluable experience. The feeling to meet Dav, Luke, Tilo, Eric, Caridy, Matt, Satyen and of course Jenny — people you’ve seen only online — cannot be described. Talking to them helps to understand their personality, what is driving them forward, what makes them happy and why are they so passionate about YUI. One of the most disappointing things for all members of the community is when you send a pull request you think it is great, but it remains unmerged. Being there I could ask, “Hey, Dav, what happened with my pull request?” and hear, “Oh, man, I’m sorry, I’ve been working for the past three weeks on yogi, but I promise I will do it very soon”. Then you understand and give allowances for the time they need.

There is also something else: watching the videos on YouTube does not allow you to ask right there if you don’t agree with something. For example, I disagreed with some parts of Ryan Grove’s presentation (mostly his pieces of advice to avoid some of Y.Lang functions), but being there was a good chance to discuss these with the presenter or with the other people from the community. Also, it’s easier to learn about the things they are already working on, but since they are in the early phase they aren’t still made publicly available. This helps to plan your work better and not duplicate what they are already working on with what you plan to do. The conference itself was very well organized, there was enough time between talks, the food was very good as well. At the and, I would like to say “thanks” to both Liferay and YUI Team for the priceless time I had the last week. Hope to see you again!

About the author: Iliyan Peychev started as a C developer eleven years ago, when he was writing software for banks and other financial institutions. Then he became Java developer working in the area of SmartCards and Security. Today he is fully devoted to JavaScript and front-end development, and he is highly interested in server-side JavaScript, real time data processing and remotely controlling and monitoring various devices and systems.


  1. It was great to meet you, Iliyan! We didn’t actually get a chance to discuss your objections to my Y.Lang advice after my talk, but I’d love to hear your feedback. Feel free to hit me up on IRC or email (ryan at wonko dot com).

  2. I completely agree. The talks are great references, but they can never contain the whole story. The live Q&A and hallway conversations are so incredibly valuable to go deeper on talk content (some of the best discussions I’ve had all year). But also, they strengthen the bonds between the *people*, and afford the opportunity to just have fun together!

    It was great to finally meet you in person, Iliyan!

  3. It was great finally meeting you in person Iliyan! I promise, I will get to that pull request very soon!

  4. Iliyan Peychev said:
    November 29, 2012 at 3:49 pm

    It was pleasure to meet you too, Ryan :)

    So here is where I disagreed:
    The API of Y.Lang is good. isString is way better than typeof o === ‘string’ (not to mention that === is redundant, typeof always returns string, so == is enough)

    There is no reason to avoid them, most of them, under the hood, do the same – plain typeof, like:
    isString = function(o) {
    return typeof o === ‘string';

    Apart from that, if you take look here at these tests:

    you will see that jQuery’s implementation of isFunction is even slower.
    The point is that nobody measures this, because this is micro-optimization and it’s not worth measuring.
    If some Web developer starts measuring how much time isFunction takes in his application, this means:
    1. His application is perfect.
    2. He is wasting his time trying to resolve performance penalties where they never existed.


    @luke & @dav
    Thanks guys! Looking forward to see you again!


  5. @Iliyan: You say `Y.Lang.isString()` is way better than `typeof o === ‘string’` because it’s literally just doing `typeof o === ‘string’` under the hood, but this is exactly why I think you *shouldn’t* use `Y.Lang.isString()`. There’s no actual benefit to it, and it incurs function call overhead.

    I’m not arguing that you should go out of your way to make micro-optimizations just to avoid function call overhead, but I don’t think typing `typeof o === ‘string’` instead of `Y.Lang.isString(o)` is going out of your way. It’s just as easy, it’s just as readable, and it’s a tiny bit faster, so what’s the point in avoiding it?

    The argument that we shouldn’t worry that Y.Lang.isFunction() is slower because it’s not *much* slower is a slippery slope. When the faster thing is just as easy to use as the slower thing, you should always use the faster thing, even if it’s only a microsecond faster.

    Spend your performance capital in the places where it really matters — the places where doing the slower thing will actually make it easier to develop or maintain your app, so it’s worth it — instead of the places where you could just as easily do the faster thing with no consequences.

  6. Iliyan Peychev said:
    November 30, 2012 at 2:40 pm

    @Ryan, I see you point and I agree with it.

    My point is that there is no need to force developers to write “typeof o == ‘string’” over and over again.
    That’s why preprocessors and compilers are. You can always translate Y.Lang.isString to “typeof o == ‘string’” when you are generating the production code and the performance issue will be resolved.

    That’s why disagreed with your piece of advice that we should avoid Y.Lang.isString. We shouldn’t. Instead, we should use proper tools to generate effective code as much as possible and offer the developers nice APIs.

  7. [...] Peychev, one of our popular community members wrote a great post about YUIConf from a YUI contributor’s [...]

  8. At my last job I implemented something very similar to Y.Lang because we needed to check for arrays and similar stuff.

    At first I only included the ones I needed (isArray, isValue). Then I was asked to implement the rest because “that way we have a consistent way of testing types”. Then I was asked that isType functions returned true for wrapper objects like new Number(5). In the end someone rewrote my implementation based on binary operations so that it could check for multiple types like Lang.isValue(foo, ValueType.String | ValueType.Number).

    I think I’d be more scared of over-engineering than performance hits.