UI Widgets… oh for something pure Grails
I feel like there is a mismatch in the grails/rails opinionated software approach and the apparent lack of a de facto and impressive UI library for javascript based web-apps built with these frameworks.
Sure, Grails has more than its fair share of UI plugins. However they all pull in other libraries, and frankly not even Yahoo UI stuff looks good enough to me. Libs such as YUI are supposed to be skinnable but the docs on actually creating skins are non-existent.
Even without those issues, you have the thorny problem that choosing a UI widget library usually dictates what JS/DOM helper library your application will use. This is infuriating if say you have an investment and passion for library X (eg Prototype) but the best UI widgets use a different underlying library.
Mixing and matching libraries in the same app is extremely unattractive. Download times become a factor as do compatibility (what if you need to use two in the same page) and last but not least your dev teams have to be fluent in more than one API.
There has to be a better way. I personally feel that out of the box one library should be chosen, and there should be great home-grown widgets. Let’s be opinionated but have something top quality out of the box.
I mean, Grails enthusiasts like me will happily point out how Rails is not on par in terms of available libraries and enterprise infrastructure stuff, and gloat at the apparent inability to create apps that don’t leak memory and hence need many restarts – but you have to admit that a great deal of Rails sites have good widgets, and good clear designs. I believe most of these are home-spun from Prototype+Scriptaculous and cunning use of CSS.
Our Javaland/Grailsland equivalents tend to reuse the standard square tables and buttons and tiny fonts so familiar to Windows users, but anathema to people who have made the switch to Mac.
This is unfortunately what you get when people are knocking together joyless enterprise Java apps and the key thing is to get something work NOW – rather than create something that is a pleasure to use. The latter is something that the smarter businesses in the Rails crowd know all about (see the excellent Harvest, Co-op, Beanstalk or Radiant), and from which all developers, Java enterprise or otherwise, can learn. Its not OK to scrimp on the UI. Who cares if your manager doesn’t get it. Take pride in UI!
Call me a snob but universally silver, sharp-edged and small fonted UIs are aesthetically offensive to me!
Related posts:
Thanks for the info. Would you recommend Grails for non-Java developers?
Yes definitely! Your learning curve when you reach outside core grails may be a bit steeper, but the grails-user mailing list is VERY friendly and helpful. The benefit is that Grails apps can use any Java code seamlessly which means there are plugins and code out there to do everything under the sun, and this is mature stuff usually
Marc,
I absolutely agree with you on the importance of a good-looking UI.
Question is if that’s the responsibility of the Grails-team. If a super sexy library comes out in the future, a plugin would allow us to use it and in the meanwhile, Grails will grow with features that help us all (also the RAD-people).
I totally agree with you Marc. I myself came to Grails via Rails and I’ve done quite a lot of javascripting.
I think the big problem is that “back-end” developers don’t take front-end code seriously enough. I mean most of us care about the code we write and the quality of frameworks and code generated by them. This doesn’t seem to go for front-end code.
This didn’t use to be a big problem, but nowadays when more and more applications runs in a browser the quality of front end code plays a big role in an application. If AJAX-functionality and alike are a part of the application, it also need to be a part of the rest of the development process. I really believe that the dividing between front-end and back-end is a bad thing when it comes to application behaviour.
Regarding UI Widgets in Grails, Rails and other similar frameworks I haven’t seen anyone that generates code that Is unobtrousive and using best practices. Instead most of them generates quite bad code, for example almost everyone I’ve seen uses the onclick attribute instead of event listeners.
What I would really suggest is that people start to use the javascript frameworks directly instead of convenience methods that’s provided by the back-end framework. Most of the api’s are really easy. You will get better controll over what’s generated and the behaviour. Of course you shouldn’t invent the wheel again, choose a library that is modular and has plugins that can do what you need it to do.
It would be great to use the jquery framework, as it has a serious (and increasing) set of UI widgets. The UI of the jquery was part of the jquery core, but now it is a separate framework, stable release.
it has a great themeing plugin that integrates perfectly with the UI. You can change your UI design in a minute by creating a new theme and replacing just a css in your app.
If you just take a look at http://ui.jquery.com/themeroller you realize the possibilities.
Hope Grails will make the right choice of choosing jquery UI.
Marc, I started a ranting comment in response to this yesterday morning, but when I got to the point where I was creating a diagram I thought I was better off writing a blog post. It became something that really is not directed at you, but just a collection of my opinions of JavaScript and the rich UI. But I think it’s still on-subject: http://weblog.dangertree.net/2009/01/12/ui-developers-learn-javascript
Hi Marc.
Hope all is well with you.
I have a more fundamental gripe with the whole web UI paradigm. There are too many disjointed technologies. HTML for content and layout; CSS for style and positioning; javascript for dynamic behaviour; and then proprietary apis for plugins etc. Its a lot of mental mapping.
We have solved the Object Relational disjoin with the OR Mapper technologies.
I’m wondering if any of the new RIA technologies will give a single approach for the web that we have for the desktop with the likes of Swing.