ZF + DOJO = Bleugh
Zend just announced their bundling the Dojo javascript library with Zend Framework (http://andigutmans.blogspot.com/2008/05/dojo-and-zend-framework-partnership.html).
That’s the last nail in ZF’s coffin as far as I’m concerned. I used to be a ZF evangelist: I loved the way you could “pick and choose” components and I definitely viewed it as a “glue” framework. Over time, I’ve grown to hate using ZF’s Controller/Views, which for web apps is a big problem; I’ve stopped recommending it to people but I would still suggest they evaluate it. Now, I think I’d actually recommend against using it.
Why? Because I feel this is the wrong direction for a PHP framework to take. I think a server-side, PHP framework, is no place to bundle a client-side, Javascript library: I am totally missing the benefits that this is supposed to provide.
In my eyes, client-side “behaviour” (ie Javascript) is completely independent from the server-side. When I develop Javascript I mentally block out the backend and am focused on DOM and the UI; if I need to send AJAX requests I see blackboxes (URLs to get/post). Likewise, when I’m writing PHP I don’t even think about Javascript: my PHP runs some logic and (probably) builds some HTML to output: it doesn’t care about Javascript.
I can see ZF heading towards being a PRADO-style framework (based on .NET ideas). I totally wouldn’t be surprised if we start to see some sort of integration with Zend_View and Dojo - like adding onClick events to <elements> from within PHP, with the onClick callback being a PHP function, executed using JSON-RPC. I don’t understand this: if you want to write component-based, event-driven web apps that look like .NET, then why don’t you just use .NET in the first place?
Mixing the server-side and client-side is a bad idea in my opinion and it moves down the “let’s abstract HTTP” path. Mike Naberezny (and Paul Jones) published some thoughts about this a couple of years back (http://mikenaberezny.com/2006/04/26/request-response-or-bust/).
Also, this reeks of corporate interference. I might have this wrong, but don’t remember seeing the ZF community desperately calling for the bundling of a JS framework? Where was the debate over which JS library should be bundled? I think it’s a joke to read Andi say “this still needs to go through the proposal process -no shortcuts!”: the CTO of Zend just announced a partnership with SitePen/Dojo - he didn’t just announce new ZF proposal.
I’ll end on a comment, from the first paragraph of Andi Gutman’s announcement (the emphasis is mine):-
“This is mainly targeted at users who rely on us to provide them with a best practice and an out-of-the-box experience for Ajax and don’t want to have to deal with evaluating a solution“
Morons, then?
Tags: dojo, prado, zend, zend framwork
May 21st, 2008 at 8:20 pm
I personally wouldn’t call our users ‘morons’. In fact, I would hesitate to call anyone a ‘moron’.
We’ve said very openly that any work we do with Dojo should serve as a blueprint for other JS toolkits as the differ widely in functionality and use- no one toolkit is the best for every situation. And if you believe that we shouldn’t integrate with any framework, then how would it affect your use of other components if you simply don’t consume our Dojo components/classes? In fact, why not just delete them from your hard drive and whittle ZF down to the parts that you agree with? 
You seem to be an experienced developer with your own well-founded opinions. Maybe there is a framework out there that fully reflects them. But I don’t really see your argument against using ZF here. The fact is, the Dojo functionality will be use-at-will just like any other part of ZF. Indeed, our controller and view components are also use-at-will, so I hope your opinion of them won’t stop you from using our OpenID or Lucene components, for example.
I can say for a fact that our users were asking for integration with a JS toolkit- usually their personal favorite.
I believe what Andi was talking about was our ‘official ZF’ recommendation of a toolkit. In fact, we do think Dojo is a great toolkit to use if one hasn’t chosen a toolkit already, and it perfectly aligns with ZF’s licensing and philosophy. In fact, people have often asked us for a direct recommendation in the past; now we’re giving them one, hopefully with some out-of-the-box support.
Also, our proposal process applies to contributors both within and outside Zend- to the extent that all internal contributors are assigned a Zend Liaison, too! In fact, internal contributors are now treated exactly as external contributors are, and they are not allowed to vote on their own proposals.
A lot has changed on the project lately. We are continually trying to improve, and I hope some people find what we’re doing useful. I’d really appreciate it if you came on by and added these opinions to the mix- we wouldn’t have much of a project if we didn’t listen to our community!
,Wil
May 21st, 2008 at 8:43 pm
Caveat: I’m a software architect for Zend Framework.
Back up a minute, please. You’re making a lot of assumptions about the partnership that are completely unfounded.
First off, yes, we are shipping Dojo with our standard distribution. However, it is entirely use-at-will, just like the rest of the ZF architecture. There is no tight integration between the two that _must_ be used. I’m creating a very thin integration with four things: a dojo() view helper for establishing the various Dojo-related script and stylesheet includes, a JSON-RPC server, a component capable of creating dojo.data compatible response payloads, and some targetted form elements that implement specific Dojo dijits. _ALL_ of this is use at will; if you want to use it, you can, if you don’t, don’t. In fact, the goal here is to provide a blue print for community contributors to create integration with _other_ javascript libraries; several have indicated they would like to do so with jquery and other JS libraries.
The ZF community _has_ been asking for a bundled JS library and/or JS integration. Why? Because it provides an easy, documented way to create web applications with rich UIs and Ajax capabilities. Why did we not leave the decision up to the community? Because we needed to be absolutely sure that the licensing, architecture, and support of standards were compatible with ZF’s goals. JQuery is a no-go due to licensing; same with prototype. Other solutions were also vetted. Dojo truly aligned best with the needs of our project.
As for future plans: no, we are not heading towards an Event-driven library. We are simply providing a blueprint and implementation that shows a recommended way to integrate a JS library with your ZF MVC application. You can use it, or not; you can use Dojo, or whatever your preferred JS library is. We still leave it up to you, the developer.
May 21st, 2008 at 10:39 pm
Hi,
When you actually look at the technical details of how we’re going to be doing the integration it is very much use-at-will and is *very* far from being a client-server component model. I know component models well and this isn’t one.
Also as Matthew pointed out lots of these pieces can either be fully leveraged (e.g. json-rpc server) and/or used as a blue print for integrating with other JS toolkits (e.g. dojo() view helper).
Re: proposal process what I meant was that Matthew would not be able to sneak in code without making sure he writes a proposal, gets community feedback and takes that into account. As we said we will also be open to having other JS toolkits supported but it is very important to make sure we make a clear distinction of what is officially supported by Zend and what isn’t. The new proposal process makes that much more clear.
Zend Framework from day one has always been super transparent about being a commercial open-source project ala JBoss. There’s a large user base which benefits from this kind project but as you know there are also other good choices in the community which may suit your preferences better. As many have already stated, Dojo does not come as a surprise to many as I have already talked about it in public and gotten feedback.
Regards,
Andi
May 22nd, 2008 at 1:18 am
Thanks for your comments.
I understand the *commercial* decision to bundle ZF with a Javascript library, and why Dojo would be the one to choose.
That said, it’s probably the reason why I will now recommend against using ZF: that it’s driven by the commercial interest of Zend rather than necessarily by the needs and the best interests of the community, its users, or The Greater Good. This particular announcement brings that into focus for me, and I think for the first time makes it an issue (I also have a gripe about Zend_Service_*, but we’ll save that for another day!).
Wil - anyone who doesn’t evaluate their technology choice before making a decision is a idiot in my eyes (and shouldn’t be in the position of choosing technology in the first place!). Thanks for your recommendation of deleting Zend Framework from my harddrive: I will be taking up your advice as soon as I can :P.
May 22nd, 2008 at 6:36 am
That’s true. We definitely try to make ZF easy to use for commercial projects. I personally don’t see any antagonism between what is good for Zend and what is good for our users. But I do understand that some people may prefer to use projects that have no commercial sponsors and are geared less towards commercial use. That’s OK, ZF would probably not be the PHP framework of choice for such users. And if ZF isn’t for you, then why waste your disk space with it? I think we’re in total agreement so far.
I think everyone has to start somewhere, and I try to keep that in mind every time I make my own recommendations. In any case, you seem like you know a lot about the subject- and I’d love to be able to convince you to take another look at the project- but best of luck with whatever library/framework you’re using. Even if it’s no framework at all!
I’m not in agreement with you on the idiot part, but that’s just a tad subjective.
And please get in touch with me or mail me blog links if you have more feedback on the framework. Yours happens to be an opinion that I haven’t run in to as much as others, and I’m very interested in what you see as The Greater Good and what suggestions you might have for ZF to court it more effectively.
,Wil
May 22nd, 2008 at 6:33 pm
I did some Googling because I wondered which JS libraries were the most used and came up with the Ajaxian 2007 Survey (http://tinyurl.com/2du8yn). I’ve also put the license that the library is released under in brackets.
“I mostly use the following Ajax frameworks, toolkits, or JavaScript libraries:-”
(respondents could select more than one)
34.1% - Prototype (MIT)
29.3% - jQuery (MIT)
22.3% - Sciptaculous (MIT)
14.3% - MooTools (MIT)
13% - YUI (BSD)
13% - XmlHttpObject directly (N/A)
12.9% - JSON (N/A)
11.8% - Dojo (BSD)
The MIT license is *more* permissive than the BSD license (the difference is normally that BSD includes a “you can’t use the name of the software to advertise your product/service” clause.
September 16th, 2008 at 4:38 am
Why dojo of all? Whats wrong with an MIT license? To be frank Dojo is the shittest JS framework i’ve ever worked with. Both its code and design philosophy are no match for competition like jQuery or Prototype.
I’ve moved from Symfony to ZF and prefer ZF even over ROR and was very excited to hear about a client library integration but I am shocked to see Dojo instead of others which are miles ahead of it.
Please explain…
October 21st, 2008 at 1:06 pm
Isn’t the point of the Zend_Dojo_* to show how to integrate a framework into Zend? If Dojo is rubbish and you dont want to use it, then surely just implement My/Jquery/* in the same style and/or put up a proposal to integrate it?
I realise that its not a trivial task, but if your working wth Zend and _another_ JS framework, then your probably doing all the heavy lifting already - if your following the ZF architectural style…
December 12th, 2008 at 10:12 am
The really horrible bit here is, after integrating my application with Dojo, or rather, moving forward with dojo integration, the entire application architecture is slowly but surely turning into a mess.
Even if we look at the simplest of applications that Matthew pushed out (pastebin), we see a scattering of processes which defy logic. Simply tasks are now convoluted and the clear separation of server and client side code is a mess. The horrible cherry on top is the debugging one has to be subjected to for the simplest of operations. How difficult is ajax? It’s mindlessly simple and can be made pretty elegant — instead, we have a huge idiotic payload to deal with and debug.
I won’t say ZF is for morons, however, I will however say that architecturally the tie-in with dojo is incredibly silly.