Related
I'm familiar with jquery and javascript but i'm a python noob. Whenever I learn something about python on the web, there's mention of django here and there. When i went to the official django site, it described it as "Django is a high-level Python Web framework that encourages rapid development and clean, pragmatic design." So I inferred it's what jquery is for javascript, am I correct?
[This might seem like a silly question but I tend to get shameless when it comes to asking questions on stack**overflow**]
I don't think it's a very useful comparison.
JQuery is mostly a wrapper around core functionality of javascript. Partly to make it easier to use and partly because otherwise you'd have to deal with browser specific problems even for the most basic scripts.
Django is a full-featured web framework that has many useful and necessary things built-in. It has request routing, templating, database abstractions, localization and a lot more.
In contrast to other web-frameworks it has those things tightly coupled and is opionated on what's the best practice to build your website with it.
A better comparison in the JavaScript world is (as an example) AngularJS. It also comes with lots of good features (routing, templating, data-bindings, dependency injection, etc.) but when you use it, you should better stick to "the angular way" of doing front-end JavaScript.
Think of JQuery more of a low-level library that you can build your code and even frameworks like AngularJS on. Kinda like the standard library of Python.
The short answer: Kind of- it is in the sense that JQuery is essentially a set of useful bits of code written in Javascript and Django the same in Python. However, JQuery is a more functional framework, where as DJango is more like a CMS framework.
No question is a silly question!
Almost, but not exactly.
I would say your python to javascript comparison is correct (as Python can be used as a scripting language for web applications, just like javascript), but jQuery is not exactly like Django.
jQuery is a library designed to simplify the scripts needed for dynamic website functionality, whereas Django is more useful in the creation of complex, database-driven websites.
Is there a bare-bones Scala web framework? I basically need the essential features such as:
Routing.
GET/POST/PUT parameter handling.
A simple templating engine (content substitution based).
Serialization (JSON, YAML)
I don't like Lift as it does too much for me, as I would like complete control over the generated HTML, meaning that I want to be able to write 100% of the HTML/CSS/JS code.
Is there such a framework? Or is it possible to use Lift in a way that no HTML is generated behind the scenes? Or would I be better of writing a normal servlet?
Perhaps you'd like something like Scalatra or Unfiltered? On a separate note, you need not give up any control of your HTML/CSS/JS in a Lift app if you don't want to.
You can just use Lift to generate services, such as REST ones, is that more or less what you are looking for? http://www.assembla.com/spaces/liftweb/wiki/REST_Web_Services
If we take a look at What Scala web-frameworks are available? none of them have a great simple templating engine, at least to me it seems that way. SweetScala seems the closest though http://code.google.com/p/sweetscala/wiki/GettingStarted
Peter gave a great answer... I'll expand on it a little.
Lift gives you a ton of control and access to raw HTTP requests as well as providing a ton of abstractions on top of the HTTP level. It's your choice on how much or how little you want Lift to do.
You can built a REST-based application using Lift's RestHelper. See http://simply.liftweb.net/index-Chapter-5.html The advantage that Lift's RestHelper gives you over most MVC/Routing based approaches is type-safety and access control at the very edge of your application. But using Scala's pattern matching extractors, you can insure that parameters delivered to the business logic of your application have already been materialized and checked for access control. Further, Lift's REST support will be as concise or more concise than other web frameworks.
In terms of Lift's HTML handling, you have a ton of control over the creation of the HTML, as long as you want to generate HTML as a valid DOM rather than as a series of Strings.
Most web frameworks force you to emit Strings when you're composing HTML. It's up to the developer to properly HTML-escape Strings. It's up to the developer to make sure that closing tags line up correctly. With Lift, you get this kind of thing for free.
You can serve HTML from Lift apps in MVC style. See https://github.com/dpp/hoisted (this is the code that powers http://liftweb.net)
In the "standard" configuration of Lift apps, Lift does some post-processing of the HTML if, and only if, you use certain construct. So, if you put a <head> tag in the body, the HTML page, Lift will take the contents of that <head> tag and move it to the head section of the page. If you include calls to Lift's Comet support, Lift will insert JavaScript on the page to do long polling. But these features are optional and they only happen if you use certain features in Lift.
I hope this helps you understand the benefits of using Lift.
Two more frameworks for you to consider:
Play is a simple REST framework that is gaining in popularity, and has a nice Scala interface. Its templates translate relatively simply into Scala functions. As of a couple months ago there were difficulties with using JSON packages (like lift-json) that unpack data into case classes because Play has a custom classloader for rapid development. Not sure if this issue is resolved. The Scala company Typesafe uses Play for their site. Play integrates with Akka, and one of the Akka lead developers, Viktor Klang, recommended Play a while back.
A little further off the beaten track, there is Spray. I can't speak to the details, but the Wiki looks intriguing. To my eyes, Spray looks to be elegantly designed around Akka integration. I don't think it comes with a templating engine, but it would probably be possible to interface with Scalate (see the mailing list discussion).
Not a Scala framework per-se, but I've had good luck with Jetty+JAX-RS+Scala+Freemarker. These are all pretty heavily battle-tested technologies, and there's no problems with Scala integration. A small shim is necessary to adapt Freemarker to understand Scala collections and properties, but nothing challenging.
Scalatra is pretty bare bones with the scala goodness. Easy to configure, easy to handle Bare HTTP stuff. It is similar to sinatra of scala.
Scalatra also has good Maven support and coexists well with traditional java servlets.
The modern Scala web framework are: Play (on Akka HTTP), Scalatra (Akka Actors) and Finatra.
https://www.reddit.com/r/scala/comments/743zjv/web_framework/
At the moment Iam evaluating java web frameworks. More precisely Iam talking about GWT, JSF2 and apache wicket. One very importent criteria in this evaluation is prototyping.
The prototyping process in my company can be described by the folloing:
The customer can produce GUIs with an easy to use WYSIWYG editor, by drag&drop-ing web components on the corporate predefined website structur. There is also a need for some litte dynamic being like navigation from one frame to another.
So Iam looking for tools. These tools should not only provide nice GUIs but also deliver
some basic code, which can be forwarded to the development. The aim is to avoid missunderstandings between designers and developers as much as possible. More or less the
developers just have to implements the code, but not to implement the optical requirements.
In addition it would be desirable to customize the components thats been used in the WYSIWYG editor. Does anyone know any good tools for the mentioned frameworks (GWT, JSF2, wicket)?
One of the challenges with WYSIWYG tools for UI is that you generally have to pick between rapid prototyping and maintainable code. Even then, as soon as you want to do something that's not supported by the prototyping tool, you can implement it as you would without the prototyping tool, but your round-trip functionality (namely turning your app back into something that can be edited) is broken or crippled unless extra work is done to generate the metadata that the editor needs.
Upgrading between major releases is another issue. Vendors and groups who have developed these tools have a historically spotty record of when they stop supporting older versions, reasonably because of limited resources and sometimes difficult problems with how to track solid innovation happening in the framework itself.
My suggestion instead is to prototype with an RIA prototyping tool like Balsamiq Mockups or use a grid system like 960 Grid to generate rapid prototypes, then use a web development framework that allows your developers to run the code with or without the backend server. Wicket has a tag called that is great for this kind of thing -- web devs can fill a div with stuff that a component should generate, and Wicket devs can wrap the contents of that tag with after they implement it. Both parties can coexist for a long time that way.
Try GWT Designer for GWT.
Introduction
Quick Start Guide
Download
There's nothing like this for Wicket that I know of. The closest you would get to any kind of resource reuse from your customer would be to give them a drag and drop HTML editor - the resulting HTML could then form the basis of Wicket page/panel layout.
if you are planing to use a javascript library, you may use extjs,
http://www.sencha.com/products/js/
they have developed a nice designer
www.sencha.com/products/designer/
there is also a port of ext in GWT
www.sencha.com/products/gwt/
You have to pay for a commercial license if your application isn't open source!
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
From the following list of frameworks, which one would you use to develop a rich web application and why would you choose it over the others?
Sproutcore
GWT
ExtJS
GXT
SmartGWT
Dojo / Dijit
Flex
Capuccino
Grails
I'm personally tired of browser inconsistencies. If someone else has solved the problem, I'd rather not do it again. That's why I'm getting more interested in front ends like cappuccino and qooxdoo. They are a zero-HTML zero-CSS solution.
These are based on my personal experiences using the frameworks you have mentioned. So yes, it is a bit biased. So as others have said over and over again, define your requirements and which one do you think fits your requirement based on what people have suggested here.
GWT is too verbose eventhough I found many Java developers love GWT because you can unit test it and it's all in Java. But I personally don't like it because it is far from being simple. There are times when I feel I can tweak a little bit with Javascript, but with GWT I am enforced to do it with several lines of Java code.
GXT is too far from GWT these days and you will find it difficult to do things as GXT has its own way of doing things which is way too different from GWT. When complex requirement come up, in the end you are going to go back doing plain GWT. And oh, their technical support is not that good either as I had several bad experiences when asking few questions to them.
Ext-JS is good for simple stuff and the look and feel is really slick. But when things gets more complex, you are going to fight you're way through. Eventhough I have dealt with the GXT tech support, I haven't dealt with the ExtJS tech support since they have different people eventhough it's in one company, so I can't say much.
Flex is nice, really nice. But again it is good for simple stuff. Once things gets more complicated you are going to write lots of actionscript, which is less enjoyable. There are many things that is available out of the box which may be to difficult if you have to code it in Javascript, like multimedia support. And oh, if you are writing for a public website you must consider that not too many user has flash plugin on their browser.
Grails, I'm not sure how you would implement RIA apps with Grails since Grails is just another MVC framework which you need to add your own RIA framework on top of it such as the ones that you have mentioned.
This is strictly a matter of opinion. You will not get any definitive answers from anyone, since anyone that answers will have one or another that they personally prefer.
Try each one for long enough to decide which one is best for your (or your team's) purposes.
That being said, I prefer GWT. Others will invariably disagree with me.
Reasons that I like GWT:
You can share (some) client- and server-side code (as long as your server is written in Java)
GWT makes a lot of advanced performance features really easy (e.g., deferred JS loading, image spriting, CSS obfuscation)
A focus on one-page apps, with third-party support for Places (using the gwt-presenter library)
It's just as easy to add GWT to an existing web page as it is to create a full one-page GWT app
UiBinder allows you to write your UI using a declarative HTML-like syntax; you're not stuck writing Swing-like UI if you don't want to
Browser incompatibilities are (mostly) taken care of by GWT -- you just write Java code, and GWT compiles it to work on every browser
Things that may make GWT not right for you:
If your server is already written in something besides Java, you will still be able to write your UI in GWT, but you'll lose out on some nice features
Compilation time using GWT is a non-trivial cost -- Development Mode mitigates this a lot, but it's still an issue sometimes
As others have mentioned, GWT can be considered "verbose" compared to simple JavaScript libraries like jQuery or ExtJS
Ext GWT has worked well for my project. The premium support has been good.
However the project is for internal use which has allowed deployment to be restricted to one browser on one OS, and no effort has been made to change the default appearance or behaviour of Ext GWT.
Developing entirely within Java is a key benefit as it helps to keep the project manageable as features are added.
I am currently working on a grail/flex hybrid app that is working a lot better than I expected. I have looked at GWT but there were not a lot of books about it at the time and it seemed to stress the leveraging of Swing-like programming techniques which I have never liked. I agree with the comment about trying them all out. Run hello app they all have and measure how hard or easy it is to modify. Also tool (IDEs, Maven, CI...etc) support can be a big factor as well in terms of being immediately productive.
We are using Grails+ExtJS here. Since we try to make an idiomatic ExtJS application, Grails is not fully utilized, though it still makes sense to use Grails instead of, say, JSP, for the server-side part.
Why ExtJS: Because it's a very rich toolkit for GUI-like web applications. Our job is to replace an old Motif GUI, so this is exactly what we need.
Why Grails: Because it gets the job done easily and quickly. For the communication with the ExtJS part, we need a lot of JSON, and in Grails it's like that:
import foo.bar.FooBar
class FooBarController {
def viewFooBars = {
def list = FooBar.getList(session.userId, params.foo, params.bar)
def result = [resultset: list] as JSON
response.setHeader('Content-disposition', 'filename="json"')
response.contentType = "text/json";
render result
}
}
And that's even two or three lines more than necessary...
Unfortunately the answer will be opinionated, GWT in it's purest form is not an eye-candy. That being said, ExtJs GXT is super hunky dory. One of the major issues I face with evolving frameworks is that they are not absolutely defect free, If I remember correctly, GWT 2.0 was shipped out with missing CSS styles for some of the new layouts. I am trying to trouble shoot an issue in ExtJs/GXT since last 5 days :(, frameworks obfuscate a lot of things. I will go with any framework that is absolutely robust and gives appropriate error messages. I haven't worked with others though.
I'd recommend Dojo.
In addition to the massive infrastructure it provides, Dojo 1.6 is also the first (and only) popular JavaScript Library that can be successfully used with the Closure Compiler's Advanced mode, with all the size, performance and obfuscation benefits attached to it -- other than Google's own Closure Library, that is.
http://dojo-toolkit.33424.n3.nabble.com/file/n2636749/Using_the_Dojo_Toolkit_with_the_Closure_Compiler.pdf?by-user=t
In other words, a program using Dojo can be 100% obfuscated -- even the library itself.
Compiled code has exactly the same behavior as plain-text code, except that it is much smaller (average 25% over minifiers), runs much faster (especially on mobile devices), and almost impossible to reverse-engineer, even after passing through a beautifier, because the entire code base (including the library) is obfuscated.
Code that is only "minified" (e.g. YUI compressor, Uglify) can be easily reverse-engineered after passing through a beautifier.
ExtJs is great for creating complex web applications. The API provides anything you can imagine in a webapp and its really easy to extend any component after some time.
You can plug it to any backend (we use django or php) and reuse or extend any component in several different applications.
You'll need severals months to feel comfortable with it. IMHO.
That said, the lib is sometimes a bit too slow for simples uis like a website (then you can use ExtCore). But when it comes to webapps this is not an issue.
Im not a java guy so GWT was not an option for me :/
hope this helps
A few years ago I did a lot of work with CGI.pm. I'm evaluating using it again for a quick project. Can someone bring me up to speed on the current state of developing with CGI.pm in the "Web 2.0" world? What are the best libraries on CPAN to use with it? Are there clean ways to include jQuery, YUI, other CSS libs, etc, and do some AJAX. There are of course lots of libraries on CPAN but what works and what is commonly used?
We aren't still doing this?
$JSCRIPT<<EOF;
...
EOF
I realize people are going to offer Catalyst as an answer. However, many people may have legacy CGI.pm apps they simply want to enhance. Is starting over really the best answer?
Personally, I'm no fan of Catalyst (too heavy for my taste) or Mason (mixing code and HTML is bad ju-ju), but I do quite well using CGI.pm for input[1], HTML::Template for output, and CGI::Ajax to provide AJAX functionality where called for.
If you're looking at frameworks, you may also want to consider CGI::Application, which is a widely-used and lighter-weight alternative to Catalyst/Mason.
[1] I can't recall the last time I called anything other than $q->param or $q->cookie from CGI.pm. There are still a lot of tutorials out there saying to use its HTML-generation functions, but that's still mixing code and HTML in a way that's just as bad as using here docs, if not worse.
Consider using something more modern, for example Catalyst. It will make your life much easier and you won't have to reinvent the wheel. I understand that it is just a small project, but from my experience many small projects in time become large ones :)
The "web 2.0" apps that I've worked with usually use client-side JavaScript to request JSON data from the server, then use that data to update the page in-place via DOM.
The JSON module is useful for returning structured data to a browser.
As far as including JavaScript, HTML, or whatever in a here doc - that was never a good idea, and still isn't. Instead, use one of the plethora of template modules to be found on CPAN. For a CGI, I'd avoid "heavy" modules like Mason or Template Toolkit, and use a lighter module for quicker startup, such as Text::Template, or Template::Simple.
Yes, you can write perfect web2.0 web applications WITHOUT using any framework on the server side in any language Perl, Python, Java, etc and WITHOUT using any JavaScript libraries/framework on the client side. The definition of web 2.0 is kind of a loose definition, and I'm guessing by web2.0, you mean Ajax or partial page refresh, then all you would really need is to focus on the following:
Know about the XmlHttpRequest object.
Know how to return JSON object from the server to the client.
Know how to safely evaluate/parse the JSON object using JavaScript and know to manipulate the DOM. Also, at least know about innerHTML. InnerHTML is helpful occasioanally.
Know CSS.
Having said that, it's a lot easier to use some framework on the server side, but not because it's required by web2.0 and it's a lot easier to use some JavaScript on the client like jQuery, mootools, YUI. And you can mix-and-match depends on your needs and your tastes. Most JavaScript provides wrapper around the XmlHttpRequest so that it works across all browsers. No one write "naked" XmlHttpRequest anymore, unless you want to show some samples.
It's perfectly possible to write "Web 2.0" apps using CGI.pm, but you'll have to do the work yourself. From what I've seen, the focus in the Perl development community has been on developing successor frameworks to CGI, not on writing helper modules to let legacy apps get bootstrapped into modern paradigms. So you're somewhat on your own.
As to whether to start over, what are you really trying to accomplish? Everyone's definition of "Web 2.0" is somewhat different.
If you're trying to introduce a few modern features (like AJAX) to a legacy app, then there's no reason you need to start over.
On the other hand if you're trying to write something that truly looks, feels, and works like a modern web app (for example, moving away from the page-load is app-state model), you should probably consider starting from the ground up. Trying to make that much of a transformation happen after the fact is going to be more trouble than it's worth for anything but the most trivial of apps.
I agree with Adam's answer, you probably want to use Catalyst. That being said, if you really don't want to, there's nothing preventing you from using only CGI.pm. The thing is, Catalyst is a collection of packages that do the things you want to make Web 2.0 easy. It combines the various templating engines such as Template Toolkit or Mason with the various ORM interfaces like DBIx::Class and Class::DBI.
Certainly you don't have to use these things to write Web 2.0 apps, it's just a good idea. Part of your question is wondering if javascript and CSS frameworks like jQuery, or prototype require anything from the server-side code. They don't, you can use them with any kind of server-side code you want.
For new apps, if you don't find Catalyst to your taste, Dancer is another lightweight framework you may like. There are also plenty of others, including CGI::Simple, Mojo/Mojolicious, Squatting...
Any of these lightweight frameworks can take care of the boring parts of web programming for you, and let you get on with writing the fun parts the way you want to.
If the jump from CGI.pm to Catalyst seems too daunting then perhaps something like Squatting might be more appropriate?
Squatting is a web microframework and I have found it ideal for quick prototyping and for replacing/upgrading my old CGI scripts.
I have recently built a small "web 2.0" app with Squatting using jQuery with no issues at all. Inside the CPAN distribution there is an example directory which contains some programs using jQuery and AJAX including a very interesting [COMET](http://en.wikipedia.org/wiki/Comet_(programming)) example which makes use of Continuity (which Squatting "squats" on by default).
NB. If required then you can later "squat" your app onto Catalyst with Squatting::On::Catalyst
There is also CGI::Ajax.