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
Related
I've been reading about Durandal and Aurelia every time I read something new on Javascript. I hear developers asking to upgrade from Durandal to Aurelia, or similar, on so many blogs. Although I do have an idea, I am confused about what the two really are and how they are related, or if at all they even are related.
Here's how I see it. Durandal is a lightweight SPA framework that allows you to leverage the best of other JS libraries and utilities to build an app. So it's not really a whole package in itself (unlike Angular), but can use different external JS libs - such as Knockout for binding, jQuery for DOM, Sammy for routing, etc.
Aurelia, on the other hand, is where the confusion comes in. Is it also an SPA framework? Or is it limited to being a client-side (front end) framework only? To add to my confusion there is a Durandal blog that talks only about Aurelia. I know from the internet that Rob Eisenberg worked on Durandal before he started working on Aurelia. So is Aurelia an upgrade of Durandal, or something completely unrelated?
I still have some questions but I'm guessing the structure of my question so far will be only asking for opinionated answers. So before this question is closed, any description, links and references in regard will be amazing. I'll be sure to update and add useful links here too.
According to Rob Eisenberg:
"Aurelia is just a vNext of Durandal. On occasion we've even called it Durandal Aurelia. Much like XBox 360 vs. XBox One. The web is significantly evolving, so we're evolving Durandal into Aurelia to match."
Aurelia, on the other hand, is where the confusion comes in. Is it
also an SPA framework? Or is it limited to being a client-side (front
end) framework only?
Yes, it is a SPA framework. Actually, it is a framework for building Javascript clients, it means you can develop apps for Browser, Desktop and Mobile. Take a look at this video https://channel9.msdn.com/Events/Seth-on-the-Road/DevIntersection-2015/Rob-Eisenberg-on-Aurelia
Different from Durandal, Aurelia comes with the full package, everything you need is there. However, it is perfectly pluggable and extensible, and you can combine any other technologies if necessary.
Here is description provided by the official site www.aurelia.io
What is Aurelia?
Well, it's actually simple. Aurelia is just JavaScript. However, it's not yesterday's JavaScript, but the JavaScript of tomorrow. By using modern tooling we've been able to write Aurelia from the ground up in ECMAScript 2016. This means we have native modules, classes, decorators and more at our disposal...and you have them too.
Not only is Aurelia written in modern and future JavaScript, but it also takes a modern approach to architecture. In the past, frameworks have been monolithic beasts. Not Aurelia though. It's built as a series of collaborating libraries. Taken together, they form a powerful and robust framework for building Single Page Apps (SPAs). However, Aurelia's libraries can often be used individually, in traditional web sites or even on the server-side through technologies like NodeJS."
Some of the greatest advantages of Aurelia (in my opinion) are:
Powerful Data-binding. Different from others frameworks like Angular, Aurelia uses new features of Javascript. So, all data-binding stuffs are usually faster in Aurelia (source http://blog.durandal.io/2015/12/04/aurelia-repaint-performance-rules/)
Simple Conventions and Simple Syntax. It is really easy to develop in Aurelia. There are a lot of features ready to use. If you want to overwrite some convention, usually 1 line of code is enough. (see http://aurelia.io/docs.html#/aurelia/framework/1.0.0-beta.1.0.3/doc/article/getting-started)
Hope it helps!
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.
My scenario: trying to port a small part of an application created by our company from native code (ObjC for iOS / Java for Android) to C-Sharp. The project will interact with our webservices. Goal of this project is figuring out how feasible it is to port our whole app to Mono.
To create URLs, I'd like to use String.Format(). I thought it'd be a wise idea to put this 'service layer' inside a Portable Class Library (PCL) since I don't expect this code to change across platforms. Sadly, it seems the String library is not available for PCLs.
So my question is the following:
I think the main advantage of PCLs over "normal" libraries is that they shouldn't need a recompile for different platforms. Is this assumption correct?
This experience makes me think that for the moment PCLs are rather limited. Should I try to stick with PCLs and work around these kinds of issues, or might it be better to stick with a "normal" library for now? --- I'll assume the "normal" library has more functionality exposed.
You can use PCLs currently across many platforms, but it does require some small hacks to your setup.
These hacks are listed in http://slodge.blogspot.co.uk/2012/12/cross-platform-winrt-monodroid.html
Once you've got those working then the functionality available is quite broad - and it definitely includes things like String.Format
For the situations where the PCL profile is not broad enough, then you can use several techniques for extending them - see http://blogs.msdn.com/b/dsplaisted/archive/2012/08/27/how-to-make-portable-class-libraries-work-for-you.aspx . The technique I generally use is to use MvvmCross Plugins - which are basically PCL interfaces with platform specific implementations. But these plugins are generally at the level of 'make bluetooth work' rather than at the level of String.Format
I do lots of PCL work across WinRT, WP, WPF, MonoTouch and Mono for Android - see http://slodge.blogspot.co.uk/p/mvvmcross-quicklist.html for lots of links to PCL work.
It's true that Xamarin have recommended not using PCLs for a couple of years, but that situation has now changed and the official support for PCLs is under way - see http://slodge.blogspot.co.uk/2013/02/the-future-is-portable.html
From a development perspective - especially from the point of view of using refactoring and testing tools - I don't hesitate to recommend you use PCLs now... especially for operations at the String.Format level. However, each project is unique... so it's not always the right answer.
One important note: right now it's better to not reuse the PCL binary files across to the MonoTouch platform - for now, build your portable libraries against the specific MonoTouch library platform. See http://slodge.blogspot.co.uk/2013/01/almost-portable-binaries.html?m=1
Perhaps you want to look at the efforts other who have got PCLs working to a considerable degree with monotouch and monodroid.
For example see http://www.slideshare.net/cirrious/mvvm-cross-going-portable . You'll also find instructions on how to setup PCL support for MVVMCross here http://slodge.blogspot.co.uk/2012/09/mvvmcross-vnext-portable-class.html .
Xamarin has recently committed to providing far greater PCL support rather than some of the workarounds that people have been having to make, but it is worth the effort.
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.
As already discussed in "Lua as a general-purpose scripting language?" Lua currently probably isn't the best scripting language for the desktop environment.
But what do you think about the future? Will Lua get so popular that there will soon be enough libraries to be able to use it like Python, Ruby or something similar?
Or will it simply stay in it's WoW niche and that's it?
I think it has a great future, a lot of projects are starting to adopt it for it's simplicity and usefulness.
Example: Awesome WM (Window Manager)
The project recently released version 3, incorporating a new configuration system completely written in Lua. Allowing you to literally write your configuration file as a program, loops, booleans, data structures.
Personally I love the syntax and the flexibility of such a system, I think it has great potential.
I wouldn't be surprised if it became more popular in the future.
Brian G
I suppose the answer starts with 'It depends how you want to use it...'.
If you're writing the common business app (fetch the data from the database, display the data in a web page or window, save the data to the database), Lua already has what you need.
The Kepler Project contains goodies for web development. Check out their modules to see some of the available libraries - there's network, MVC, DBMS access, XML, zip, WSAPI, docs...
As an example web app, check out Sputnik.
For desktop UI, there's wxLua - Lua hooks for wxWidgets.
ORM is conspicuously missing but that didn't stop people from developing in other languages before ORM was available.
If you're looking for specialized libraries - scientific, multimedia , security - don't count Lua out before you check LuaForge.
When it comes down to it, there's nothing in Lua's design that prevents general purpose use. It just happens to be small, fast, and easy to embed... so people do.
Uh? I would say instead WoW is a niche in the Lua ecosystem... The world of Lua doesn't revolve around WoW, there are lot of applications, some big like Adobe Lightroom (to take a non game), using Lua.
Lua is initially a scripting language, in the initial sense, ie. made to be embedded in an application to script it. But it is also designed as an extensible language, so we will see progressively more and more bindings of various libraries for various purposes.
But you will never get an official big distribution with batteries included, like Python or Perl, because it is just not the philosophy of the authors.
Which doesn't prevent other people to make distributions including lot of features out of the box (for Windows, particularly, where it is difficult to build the softwares).
Lot of people already use it for general system-level scripting, desktop applications, and such anyway.
There are more and more libraries for Lua.
If you are a Windows user, have look at Lua for Windows. It comes with "batteries included" (wxLua, LuaCURL, LuaUnit, getopt, LuaXML, LPeg...).
Very usefull!
It's 2017, 9 years after this question was first asked, and lua is now being heavily used in the field of machine learning due to the Torch library.
I really like it as an embedded language. It's small, very easy to use and embed and mostly does what I need right out of the box. It's also similar enough to most languages that it has never really been an issue for me. I also like how easy it is to redefine and add base functions and keywords to the language to suit whatever needs my application has.
I have used it in the WoW area but I've also found it useful as a generic scripting language for a number of different applications I've worked on, including as a type of database trigger. I like Ruby and Python and other more full-featured scripting languages but they're not nearly as convenient for embedding in small applications to give users more options for customizing their environments.
being comfortable as a shell language has nothing to do with being a great general purpose language.
i, for one, don't use it embedded in other applications; i write my applications in Lua, and anything 'extra' is a special-purpose library, either in Lua or in C.
Also, being 'popular' isn't so important. in the Lua-users list periodically someone appears that says "Lua won't be popular unless it does X!", and the usual answer is either: "great!, write it!", or "already discussed and rejected".
I think the great feature of Lua is, that it is very easily extensible. It is very easy to add the Lua interpreter to a program of your own (e.g. one written in C, C++ or Obj-C) and with just a few lines of code, you can give Lua access to any system resource you can think of. E.g. Lua offers no function to do xxx. Write one and make it available to Lua. But it's also possible the other way round. Write your own Lua extension in a language of your choice (one that is compilable), compile it into a native library, load the library within Lua and you can use the function.
That said, Lua might not be the best choice as a standalone crossplatform language. But Lua is a great language to add scripting support to your application in a crossplatform manner (if your app is crossplatform, the better!). I think Lua will have a future and I think you can expect that this language will constantly gain popularity in the long run.
Warhammer Online, and World of Warcraft use it for their addon language I believe.
I think it's hot! I'm just no good at it!
Well, greetings from 2022.
It is already a general purpose language. Today you can even serve pages using OpenResty, extend games, read databases or create scripts as shellscript replacements.
There are a plenty of libraries "modules" for Lua, many ways to achieve what you are wanting and Lua 5.4 is even faster.
The "extendable and extensive" nature of Lua, accostumed people to think it should only be used as plugin or extension. In Linux, by example, you can shebang a file with lua-any, make it executable and run like any system script. Or you can make a folder app like Python or virtualenv using Lupe. Lua 5.3 also gained impressive performance improvements.
Also there are many good tools like IUP to create native windows in Lua for Mac, BSD, Linux and Windows and side environments like Terra that lets you use Lua with its counterpart Terra and write compiled programs. Lua now, is more than a extension language, it has its own universe.