i read about the Google Closure Compiler and i will try to use it to make my web application better. But i think it is doing the same things like the dojo shrinksafe.
Has anyone tried to use the Google Closure Compiler for a complex dojo project?
Thanks
Benjamin
Yes, Google Closure Compiler works fine with Dojo projects. Because Closure is derived from Dojo, it has similar concepts (modules, loaders, the build, and so on) so it is potentially possible to use some advanced features of Closure Compiler with Dojo, which go beyond simple minification.
We (Dojo) will evaluate what we can reuse and leverage from Closure and how we can improve interoperability. Obviously it will include all tooling too.
Closure will probably work with any valid javascript code. I fed it an extremely packed, obfuscated version of a complex Prototype project of mine and it spit out a perfectly working version. So even if your code has already been shrinked by Dojo, you can probably use Closure on top of it. You should, however, choose one of the two.
As of Dojo 1.4 (not yet released, but the code is in the subversion trunk of Dojo), you can now use Closure Compiler as an option for the Dojo build process. It takes a bit of setting up. Instructions on how to use Closure Compiler with the Dojo build system.
Dojo 1.6 is compatible (after some minor modifications) with Closure Compiler in Advanced mode.
http://dojo-toolkit.33424.n3.nabble.com/file/n2636749/Using_the_Dojo_Toolkit_with_the_Closure_Compiler.pdf?by-user=t
Stephen
I happen to have a 12,000 (26,000 if you include dojox/dijit imports) line dojo 1.3.2 application I am about to release.
Well I used the standard dojo build system to throw it all into one lovely big one megabyte file. Then I introduced it to the google closure compiler, the compilation went very well reducing the package down to 350 kb, 100kb less than yahoo ui, and 150kb less than shrinkwrap. I, of course, did it all in advanced mode like a man.
So far so good, then it was time to load it up! The results were mixed. The site did seem to work, but I did get quite a few pesky errors telling me that various things behind the dojo prefix could not be found. I wasn't able to work out exactly what was going on as I didn't have closure addon for firebug ready, but I didn't notice issues the actual operation of the site - though I posit if I looked hard enough I would have found them.
So I thought to myself it appears the closure compiler is renaming dojo name space in my compiled.js to make them inconsistent with dojo.js. It seemed like an ideal solution was to combine dojo.js.uncompressed.js with my blob.js.uncompressed.js using the closure compiler. This resulted in a 51kb reduction in the size of the dojo library so far so good! Bad idea dojo didn't much like this at all and refused to load! It just downloaded then just sat there in protest of google's world domination.
I have done some further research into this matter, from what I read dojo 1.4.0 does support closure in 'simple' mode, but this is rather pointless because as I read closure simple mode provides a similar amount of compression to yui.
Anyway, those are my thoughts, I have looked at closure a little, it looks like a very nice library. The css layout looks drastically simpler than dijit's, this is something I am very fond of, I've often found it easier to rewrite dijits than try and theme them correctly. It seems to be missing some elements of the dojo library I am rather fond of such as dijit._Widget, dijit. _container/contained and of course the famous dojo.declare(). I suppose I could rebuild these, but why should I?
Addition:
Oh it also appears to be lacking a good RPC, cometed framework, and publish/subscriber framework. Unless I am mistaken. Don't get me wrong I want to like closure, I'm not a dojo apologist by any stretch of the imagination, I just like these parts of dojo. The addition of require and provide does make this a serious contender from my perspective. The lack of a meaningful system of this nature drove me away from jquery.
Related
I'm using Vuetify Vue3 for a project. There are some components missing that are available in other fw. Does this cause messup in the project by installing extra fw for one component?
You can indeed have several frameworks at the same time, but it may drastically impact your performance and lead to messy code because of the difference in APIs.
If you are meaning, CSS like a UI framework (Vuetify, Bulma, Bootstrap etc...), the answer is the same. Doable but quite heavy.
Nothing stopping you from going crazy by using all of them!
Technically, you can use at the same time, but if you mean CSS frameworks sometimes it can lead to conflict between classes.
It is not recommended and best practice to do that because it can cause a conflict and also can make your application heavy.
But it is not forbidden and you are free to try.
I am working on enterprise-level business applications, and now is the time to start thinking about the non-desktop experience.
We have a common component code-base that is using dojo, and are trying to get as much code re-use as possible.
I am really struggling to determine if I should re-use the same code base, or have separate code bases for desktop and mobile.
A big factor in my decision making is the viabliity of dojox/mobile.
It seems pretty cool, and uses the dojo infrastructure which is a huge win, but the fact that it is in dojox scares me a little.
Some questions:
Is dojox/mobile something that can be relied on long term?
Is it a smart idea to try to swap out dijit components for dojox/mobile components depending on what has.js can tell me?
Will dojox/mobile be a part of dojo2.0?
I would add that in Dojo 2.0 the plan is to converge as much as possible the desktop (dijit) and the mobile (dojox/mobile) widgets which should help in your use-case. See: http://mail.dojotoolkit.org/pipermail/dojo-contributors/2013-June/029041.html
You can rely on dojox/mobile. DojoX will indeed disappear from the Dojo Toolkit in 2.0, but most matured (and probably maintained) modules will be pushed to the dijit/dojo library. I quote the reference guide:
In the future (Dojo 2.0), the DojoX package and namespace will
removed. Sub-Packages and modules will be either integrated into the
Dojo Core, Dijit or separated as their own stand-alone package. For
the 1.X code stream though, in order to ensure backwards
compatibility, all these packages are contained within the dojox
namespace and package.
If we look at the explanation of Mature, we can read the following:
This package or module is considered mature and is being actively
developed and maintained by committers within the Dojo Toolkit. It is
expected that it will persist into the foreseeable future.
Source
And if you look at the link above, you will notice that dojox/mobile is categorized as mature.
Another reason you can rely on it is that IBM (which can be considered a pretty big company and committer to the Dojo toolkit) also relies on dojox/mobile for their mobile product called IBM Worklight. If they rely on it, then there's no reason you couldn't.
I don't think it will be easy to start from the same code base and swap out dijits for dojox/mobile components. Usually mobile app development requires an entire different strategy than web applications. You will probably have to split certain things into multiple views and some dijits may not have a mobile alternative.
You can probably re-use most of your utilities and business logic, but I think you will have to start from scratch again if you want to write your view(s). But I'm not really an advanced mobile developer.
I'm architecting an enterprise web application using python, django. My final decision to make is which javascript library to use. I'm thinking about using Google's closure library or YUI3. Most of the development, I've used jQuery.I can code fast with jQuery but doesn't seem right for enterprise use.
YUI 3 seems pretty good. It includes most widgets I want to use, but Closure library does almost the same. Better offer with Closure library is they have Closure Compiler, but seems like Closure requires to write much more code than YUI 3. Documentation from YUI 3 is pretty good too.
The application will be for both web and mobile devices, so the library should not break in mobile device such as Android or iPhone.
If you were me, what decision would you make?
Disclamer
I mostly draw on comment about jQuery in enterprise environment and since I lack experience in YUI, I can not give any conscious advice for [not] using it over Closure.
But in lack of any other answers I'll share my experience with Closure.
Closure library
As for Closure library, which I have been using for last few projects but am, by no means, expert at it, I can say only good things.
Library provides the core components you need when building any kind of UI. But, unlike jQuery, it does not come with trillions of "ready-to-deploy" plugin-in scripts, or as some would say, with no batteries included.
It's got basic events, controls, xhr, dialogs, form components etc., and by my account the most important thing, namespaces (or at least something looking like them...).
With this you can create your own custom UIs limited only by your imagination and the power of JavaScript (and JS is very powerful language even if it does have its own annoyances).
And with help of Closure compiler, which not only minifies the code but it excludes all unused code, does type checking, gives warnings useful for debuging and so forth, it looks like solid foundation for building large applications ground up by teams of any size.
In my opinion, main reason for using Closure over jQuery in enterprise projects is consistency. Plugins are awsome but they tend to include inconsistency at all levels, either programming practices, visual styles and structure, performance, usage, you name it. Removing these small inconsistencies on large project can waste lot of time.
So in conclusion, if you have large project needing custom UI and a lot of flexibility Closure is the Right tool for the job. And with "namespaces" it even feels all Pythonish.
P.S. We also use Django on server side.
You have touched on most of the important aspects here, the type checking, minification, namespaces, but I would like to add a few more. Alongside is the templating sollution they offer, which is not only super fast and has full internationalisation support, this mixes in and compresses with the library. It also compiles down to java code so you can render on both the server and the client from the same template.
Then there is the component architecture which has a complete livecycle, seperates renderers from components, (if you are familiar with swing or flex you will get the idea), it has two models, one is client side rendering and the other is decoration which plays beautifully alongside the server side rendering.
The testing sollutions are well defined and now the
We have thousands upon thousands of lines of javascript and without closure it would have been an unmaintainable mess IMO.
I'd go with YUI 3. Especially if the only reason you're considering Google's Closure is the compiler. As this works well in YUI 3, with much better compression than the YUI compresser. I'm sure it doesn't do as good a job as it could with Closure code, but that's pretty hard to test.
The modular framework in YUI 3 is awesome, and there is enough sugar to give you a tooth ache without being too heavy. Yahoo use it for all their sites, and they have a strong emphasis on performance (so it can't be all bad).
In the tests I made, Google Advanced Compress is the better, and after the the Yahoo! YUI Compressor. You can make the tests here:
http://jsperf.com/closure-vs-yui
We are in the middle of a relatively large project which uses ExtJS3 and have already invested ~4 man-years, using several plugins and we have written some plugins ourselfs. After a quick glance at ExtJS4, it seems that we would have a lot of work to do to migrate the project to ExtJS4. Are there any strong reasons to switch to ExtJS4? Currently, it seems to me that compatibility with future browsers (or the lack thereof) is the only one.
We're in similar situation and our conclusion was to wait a bit more as Ext 3 is doing it's job. We experienced many problems in our "test" migration and I would say that it's more a rewrite of the application than a migration :(. Also, our experience showed that Ext JS 4 has some performance problems, forms are a bit different, store cannot reject changes, it's bigger. There are some very good new features like the new class system, mixins, new charts, ...
We have upgraded our application to ExtJS4 without fail.We are happy to say that ExtJS4 is fast compare to ExtJS3.A new class system,mixins,plugin-free charts,focus management...etc.,. But if you want to upgrade you need to change a lot of code because class system and config options are changed.We have tested the performance of our application using ExtJS3 and ExtJS4,so as per our observation ExtJS4 is fast and it will not break.As per our observation,CSS selectors are also changed if you want to customize the component you can easily do the thing in ExtJS4.
We tried to migrate from ExtJS3 to ExtJS4 previous week. Unfortunately I must say it is like translate english to german. A lot of work. From our point of view more or less just the charting system is plus, minus - a lot of components that we use are not supported, a lot of css customization shoud be done, working code in ExtJS3 breaks easily and there is sometimes almost impossible to find an error.
Not an expert but personally I'd start new project with extjs4 but leave exiting project alone. The charting stuff is amazing in 4!
I think Xcode is a good IDE, but having used Eclipse for Java development in the past I am quite underwhelmed by XCode's code completion and error/warning feedback. (Most of the time, XCode seems to simply try to match the beginning of a text fragment to "words" in the same document, without even using type information to try to determine the appropriateness of a suggested completion.)
Does anyone have ideas or tricks to make XCode approach Eclipse's cleverness, or to realistically develop Cocoa apps with other IDE:s than XCode?
EDIT: Worth keeping an eye on this: code.google.com/p/objectiveclipse/
The good news is, Apple’s working on the problem. One of the goals of the clang compiler project is to create a reusable parser which can be used for better code completion and refactoring support. Indications are that this has borne fruit in the latest Snow Leopard seeds.
Quite simply: no.
You can do almost everything by hand using your favorite text editor but it's not at all recommended. Try designing interfaces without Interface Builder for example.
My advice would be to just stick with Xcode and learn its way of doing things. Yes, it will be different and sometimes might not be "better" in your Eclipsed eyes. Console yourself in the fact that Apple's managed to release some great products using Xcode.
My personal experience is that, each time I use Xcode, I find a new trick which I can add to my bag. Xcode is far more full-featured than what you might think at first (or second) glance.
I've long voiced my rants about what's wrong with Xcode (and what's not wrong with Xcode). But you really don't want to use another tool. And without breaking NDA: Xcode 3.2 with SnowLeopard: Hooray. (Compared to what we have; not compared to what we might want.)
That said, to your original question about code completion, I personally turn off auto-completion in favor of on-demand completion. I find it far more useful and less distracting. In the Code Sense panel, set "Automatically Suggest" to "Never" and make sure the other two options are selected ("Show arguments in pop-up list" and "Insert argument placeholders...") This will do completion in a pop-up box when you hit Escape, making it easy to scroll through looking for what you want. I find that I have to type a lot less this way, especially for methods that are not unique for many characters. 80% of the time, it's highlighting the right thing already.
I have certainly felt your pain — as an experienced Java developer and frequent Eclipse user, I've wished for the same features myself. Unfortunately, I'm not aware of anything that fits the bill. I don't think there was any satisfactory resolution to this SO question, either.
However, I think you'll be quite happy with the improvements to Xcode code completion coming in Snow Leopard — it's vastly smarter about filtering the list of possible completions. Also, there are new conveniences for coding, such as inserting a starting bracket when you forgot one, etc. To my knowledge, there is still no predictive compiling like Eclipse, though.
Is anyone aware of an IDE other than Eclipse that supports predictive compiling and warning/error reporting? Does Eclipse itself support the feature for languages other than Java, such as C++? I'm led to wonder whether the fact that Java is built with independent .java files rather than .h and .c/.cpp/.m files makes it simpler to predictively compile. Also, anything compiled with gcc requires a little more care and attention than the comparatively simpler javac command. Any thoughts?
Check out JetBrains' new IDE called "App Code". It's still in the Early Access Program, but even with the Early Access bugs it is hands-down better than xcode 4.
http://www.jetbrains.com/objc/
emacs and/or vim
Xcode does have some context awareness, when you are sending a message to an object it will generally have the "ESC" list pull up meaningful arguments.
One thing I strongly recommend is looking into text macros. These are not really type aware, but they can save a ton of typing - for instance, after #implementation type "init" and then hit control-. (period) to activate the text macro. It will fill out a whole init method for you. You can create your own, or override the existing macros.