Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
There are a few web frameworks for Clojure
Compojure
Webjure
Conjure
Moustache
and also some libraries for dealing with certain web development subtasks, such as
Enlive for templating
Hiccup for templating
Ring to handle lower level stuff with requests/responses
ClojureQL for persistence (it doesn't seem very active, though)
There are also hundreds of Java libraries to be used. Some aspects were already discussed here and two of them compared a bit.
I wonder how these frameworks/components compare in terms of maturity, scope, ease of development, Django/RoR feeling, etc.
When I first started with web development, it was with Clojure. I had no prior experience with web development at all. I could not, for the life of me, figure Compojure out. I don't know if beginner documentation has been improved since then (it wasn't that long ago) or not, but at the time, I couldn't manage it. A friend pointed me to Moustache and after reading the README, I was able to throw together what is http://try-clojure.org in it's current state. So, as far as ease of use goes, I think Moustache takes the cake for me.
However, if this has existed at the time, I might be singing a different tune.
Conjure looks very cool, though very different from the other frameworks. Given my very limited experience with web development in general, I don't have much say in this matter, but Conjure feels kind of unclojurey to me. It just doesn't feel right. It may just be that I'm not used to the way it does things.
UPDATE: It has been a while since I wrote this. Lots of things have changed. Not many people use Moustache anymore, and it isn't really actively maintained, though it was complete enough (and simple enough) that it probably still works, I'd now recommend going with Compojure or Noir instead. Both of these are currently maintained frameworks and both are excellent at their job.
UPDATE 2: Noir has been deprecated for quite a while and most of its functionality moved to a library designed to be used from compojure/other ring-based web frameworks called lib-noir.
I know this question is a bit dated... but I couldn't help but suggest Noir as a very nice option.
Noir uses a combination of Ring, Compojure, and Hiccup to get the job done. Check it out!
As mentioned in Bjorn Lindqvist's comment above, Noir is dead. Details here.
Instead, consider using Compojure and lib-noir.
Thinking in terms of frameworks is probably a mistake. The better approach is to think in terms of library components which you put together in order to have the 'framework' which best suits your requirements.
I have used a number of frameworks in the past. Most of them do a reasonably good job at getting you up and running with a basic application quite fast. However, without exception, I have found all of them just get frustrating more often than not. Often it is due to too much boilerplate or just having to jump through hoops which are not relevant for the application your developing.
When first coming to Clojure, I started looking for frameworks, but then realised this was the wrong approach. Instead, I found it much better to just start with a basic ring application and then add libraries as I needed them. This can seem like a bigger learning curve to start with, but in fact it turns out to be just as efficient because your not forced to learn a whole heap of framework scaffolding which you often don't need.
However,I have found looking at various frameworks really useful as it gives me ideas of how to best integrate a library and more importantly IMO, how you can best structure your lein project.clj file to best suit the workflow you want.
I've found the following templates really useful. I don't use any of them 'as is', but have adapted/stolen ideas from many of them to develop the frameworks which best suit the app I'm working on
Luminus and Luminus templates provides a very extensive framework. I find them a little 'heavy' for many applications, but there are some great examples of how to integrate various Clojure libraries into your app. The main website also has some useful documentation.
Reagent Project, which includes a reagent template provides a good starting point for an app using Reagent (react.js) ClojureScript support. I've found this to be one of the easiest ClojureScript libraries to create an app with good Javascript integration.
lein-figwheel is a really interesting template using figwheel to provide dynamic loading of clojurescript so that you see your ClojureScript changes in the browser as you modify your code. Many other templates have now added this functionality to their own templates. Originally developed with Om in mind, Luminus and Reagent templates now also integrate Figwheel functionality in their templates. Really shows some of the benefits of Clojure and ClojureScript for interactive development.
Compojure Template is a great starting point. It sets up a very basic compojure based project with all the basic ring and compojure stuff. Great way to start with Clojure web development because it is simple and allows you to focus on the basics before drowning under all the other options.
There are many other templates and frameworks, many of which I've not had time to look at yet. These days, I often start with either compojure template or reagent template and then add additional bits if and when required. I usually also include selmar for templates and use essentially the same configuration Luminus uses.
Perhaps the most important part of getting a good 'framework' for you web development is to experiment and understand how lein works and the lein project.clj file. Having a good project.clj file will determine your workflow. Having the right profiles, ability to start the repl in different ways and load different libraries which allow you to kick off figwheel or a browser repl or generate a jar etc is all about your project.clj file. Get this right and your environment will provide just the workflow you need.
A new player appeared in the scene as a good alternative to implement REST services is liberator. It makes easier to expose your data as resources while automatically complying with all the relevant requirements of the HTTP specification RFC-2616 and plays nicely with http-kit and Compojure.
Pretty happy with http-kit btw, the live code reload feature is handy.
try road framework for fast web dev
https://github.com/zhujinxian/road
(defn render-test [ret tmt]
(-> (resp/response "------render----test------")
(#(resp/content-type %1 "text/plain"))))
(defn foo
"I don't do a whole lot."
[x]
(str "来自源码目录的参数：" x))
(defn handler [^Integer x]
{:$r render-test :text (str "hello world, road goes sucess!" (foo x))})
(defn home [req content ^Integer num]
{:hiccup "home.clj" :content (str "home" content) :num num})
(defroad road (GET "/web-test-0.1.0-SNAPSHOT-standalone/main" handler)
(GET "/web-test-0.1.0-SNAPSHOT-standalone/home/:num{\\d+}" home))
(defn -main [& args]
(log/info "---------log4j test-------")
(jetty/run-jetty road {:port 3000}))
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
What are the current choices of mature Clojure web frameworks? I am looking for some kind of feature matrix telling me what the popular frameworks support and to what extent, including:
Response templating (response written in Clojure or in some other markup - e.g. like JSP with Tiles)
HTTP sessions
REST with automatic mapping of URLs into action-functions and params
HTML forms (params available as map, error handling, validation)
Application flow (known from Java frameworks - request handlers return action identifiers which are eventually handled by renderers)
Perhaps my answer to the What is the good starting point to developing RESTful web service in Clojure? question on SO might be of help to you. It mentions some important web libraries for Clojure (with links and short summaries). The key point which I would like to reiterate here is stated in the first paragraph of that answer:
First of all, I think that you are unlikely to find a single shrinkwrapped solution to do all this in Clojure (except in the form of a Java library to be used through interop). What is becoming Clojure's standard Web stack comprises a number of libraries which people mix and match in all sorts of ways (since they happily tend to be perfectly compatible).
To that I would add that you should probably not expect to handle things with the sort of "application flow" you might know from Java (or if you believe you really need it, you'll probably have to roll your own lib to support it!). That's alright, though, as people seem to be very happy with Ring's handler-is-a-function, higher-order-middleware-friendly approach.
To address your bullets:
Response templating:
There is a number of Clojure-specific solutions, including Enlive and Hiccup (Enlive is a very powerful HTML scraping / templating / transforming engine; Hiccup is a DSL for writing HTML in Clojure with the nice property that it renders fast). Also, this is probably one place where it makes perfect sense to drop down to Java and use something like, say, StringTemplate. This even has the good side of discouraging the mixing of templates and logic! (I believe Stuart Halloway has mentioned that Relevance -- his company -- is using this strategy in their work and having great success with it.)
HTTP sessions
That would be Sandbar, I suppose. The author has started a series of blogposts about it which looks very promising.
REST with automatic mapping of URLs into action-functions and params
That's Ring & Compojure and/or Moustache. See below.
HTML forms (params available as map, error handling, validation)
As above.
Application flow (known from Java frameworks - request handlers return action identifiers which are eventually handled by renderers)
As mentioned above, not really something people tend to do in Clojure.
As a starting point in learning about the Clojure web stack, this Ring tutorial by Ring's author Mark McGranaghan is very helpful. Compojure's author James Reeves has some documentation on Compojure. Perhaps my recent answer to the What’s the “big idea” behind compojure routes? question might be of help too. Ring's sources also include a great SPEC document.
Since this question was originally asked / answered, the Noir web framework has emerged as a promising solution.
It uses hiccup for the templating part, but offers a more complete framework around that.
Basic code sample from the Noir main page:
(ns my-app
(:use noir.core)
(:require [noir.server :as server]))
(defpage "/welcome" []
"Welcome to Noir!")
(server/start 8080)
I will recommend you to use Luminus, not because of its awesome name, but also its feature.
And since Noir is no longer maintained, I won't recommend you to use that.
It is also a good choice to start from ring & Compojure from the very beginning to build your own framework.
You may be asking the wrong question. What I'm seeing in your question is "what Clojure framework is most like the Java Object-Oriented frameworks I'm used to?". There is no good answer to that; if you only feel comfortable with a state-ful server-side approach (such as Grails or Tapestry) then perhaps you should stay there, and find a way to implement some of your backend in Clojure.
On the other hand, if you want to build something more true to Clojure, you may want to find your own mix. I've had some good success using AngularJS and CoffeeScript on the client, and Clojure (using Ring and Bishop) on the server (though we are moving from Bishop to Liberator). In any case, once you embrace the "single page" web app approach and start treating the server-side as a source and sink of data, you'll find Clojure works exceptionally well.
try road framework for fast web dev https://github.com/zhujinxian/road
(defn render-test [ret tmt]
(-> (resp/response "------render----test------")
(#(resp/content-type %1 "text/plain"))))
(defn foo
"I don't do a whole lot."
[x]
(str "来自源码目录的参数：" x))
(defn handler [^Integer x]
{:$r render-test :text (str "hello world, road goes sucess!" (foo x))})
(defn home [req content ^Integer num]
{:hiccup "home.clj" :content (str "home" content) :num num})
(defroad road (GET "/web-test-0.1.0-SNAPSHOT-standalone/main" handler)
(GET "/web-test-0.1.0-SNAPSHOT-standalone/home/:num{\\d+}" home))
(defn -main [& args]
(log/info "---------log4j test-------")
(jetty/run-jetty road {:port 3000}))
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
I realize that this may be subjective but I truly need an answer to this and I can't seem to find anything close enough to it in the rest of the Forum. I have read some folks say that the framework (any MVC framework) can obscure too many things while others say that it can promote good practices. I realize that frameworks are great for a certain level of programmer but what about individuals starting out? Should one just focus on the language or learn them together?
I think web development is way more than anyone grasps when they first start getting into it! Read this and know that it is all optional...but required to be really good at what you do.
I suggest that you spend time learning your language first. I would suggest learning C# simply because it is vastly more marketable and it is usually directly supported in most of MS products. By learning C# - programming in ASP.NET, console apps, servers, services, desktop apps, etc. will all be within your reach. You can program for most of the MS products as well as on many Linux type platforms.
Once you have this down then you can move to programming for the web as programming for the web has some intricacies that most other environments don't have. Concepts such as sessions, caching, state management, cross site scripting, styling, client side vs server side programming, browser support, how HTTP works, get vs post, how a form works, cookies, etc. are all at the top of the list of things to learn separately not to mention learning the ASP.NET base frameworks and namespaces.
Once you have the programming language down and then the concepts of web programming I suggest that you pause and learn database design. Don't worry about performance just yet...try to first learn good design. Performance will come next. A good start for you is Access (blasphemy I know). It is easy for a beginner to work with. And it translates into a more robust platform such as SQL Server easily. Learn at the very least some SQL...but I suggest that you learn as much as your stomach can handle. I heard someone say that SQL is like the assembly language of the database. The number one thing that slows an application to a halt is piss poor database design and poor queries. Once you have this knowledge - stuff it away in the back of your mind and take a look at a good ORM. NHybernate is probably best at the moment but is more complex that the basic learner needs. For that reason I currently suggest getting LINQ to SQL up and running as it is SUPER EASY to work with. Then look at Entity Framework (although I still think it sucks...and you should wait till EF 2.0...ERRRRR...now 4.0 released with .net 4.0). Then NHybernate.
Now is the time to start to understand the infrastructure that is required by web development. You may bump your head against this as you learn some of the web programming stuff. But you need to understand the basics of DNS, IIS, load balancers, sticky routing, round robin, clustering, fault tolerance, server hardware setup, web farms, cache farms (MemCached Win32, Velocity), SMTP, MSMQ, database mail queuing, etc. Many people may say you don't need this. That there will be some knowledgeable network admin to help you out here. However they generally know things that impact them...not you. The more you know here the more valuable you will be to the company that hires you.
Now you can get into the details of best practices and design patterns. Learn about the basics such as repository pattern, factory pattern, facade pattern, model view presenter pattern, model view controller pattern, observer pattern, and various other things. Follow Martin Fowler and others for suggestions here. Take a look at concepts such as inversion of control, dependency injection, SOLID principle, DRY, FIT, test driven design, and domain driven design, etc. Learn as much as you can here before moving to the next step.
NOW you can think about frameworks! Start by creating a basic application with ASP Classic (comes with IIS for free!). This will give you a flavor of a no frills web development environment. Take a look at ASP.NET web forms (briefly) to see how MS attempted to make things easier by hiding all the complex stuff (which you now know how to manage on your own from your readings of the above materials!!!). Now you no longer need ASP.NET Web Forms. Move immediately to ASP.NET MVC. The MVC framwork gives you all the power you need to create a good easily manageable web application. If you build something really big no framework for pure web development may be able to deal with what you need. However MVC is way more extensible for such UBER custom scenarios.
Now that you have made it through the journey to ASP.NET MVC you can take a look at things such as Microsofts Enterprise Application Blocks (such as they use at MySpace). Take a look at Elmah error logging (a must have). Look at how to build a custom SiteMapProvider for your MVC site. If you need to get into searching stuff understand Lucene.NET.
And if you made it this far...you are ready to figure out the rest on your own as it comes up! Have fun. There is a lot of room in this space for a person with some understanding of all of the above concepts.
You'll be using SOME sort of framework. The question is, what level do you want to learn at?
You'll probably not care to learn about asynchronous I/O and mutlithreaded vs. select/poll styles of web servers.
So then, your language of choice is going to provide a layer atop this, the languages preferred "web interface" API. For Java it's Servlets, the lowest level you'd typically code at for server side web applications.
You should find what this "lower level" layer is in your language and learn the API at least. You should know basic HTTP like status codes, cookies, redirects, POST vs GET, URL encoding, and possibly what some of the more important headers do.
You'll then come to appreciate what these higher level frameworks bring to the table, and be better able to evaluate what is the appropriate level of abstraction for your needs/project.
Web development requires a certain degree of organization, since it relies so much on separation of concerns. The browser, for example, is designed to display data and interact with the user. It is not designed to lookup data from a database, or perform analysis. Consequently, a web development framework can help provide services that are needed to make the browser experience a practical one.
The nice thing about employing a platform is that it will provide core components essential to the making of any web application that you won't (and shouldn't) have to think about, such as user membership, for example. Many of the design decisions and deep thinking about how to implement these services has already been done for you, freeing you to focus on what you actually want you application to do.
Of the available frameworks, I find that frameworks that implement the MVC (model-view-controller) pattern are very practical. They clearly organize different functions of web development, while giving you full control over the markup presented to the browser.
All that said, you will need some fundamental skills to fully realize web development, such as HTML, CSS, and a core programming language for the actual underlying program, whether you use a platform or not.
I don't think I agree with the Andrew. I don't think learning C is a pre requisite for web development. In fact, learning something like Javascript, Action-script or PHP is often easier due in large part to the vast numbers of sites and tutorials available, and are enough to expose you to the fundamentals of pretty much every programing language. Variable, Conditions, Loops and OOP. I just think learning C# introduces a lot of learning that isn't really relevant to web development such as pointers and memory management.
As for wether you should learn a framework first? Definitely not. Never ever. You need to be able to stand on your own two feet first and be comfortable with HTML/CSS, Server Side Scripting (PHP/ASP/Python/Ruby whatever) and love it or loathe it, but you're going to have to have a decent understanding of Flash and Action-script.
The order in which you learn these is entirely up to you. But my learning plan would go like this...
Start with HTML. It takes about half an hour to get the basics (it's made up of tags with attributes, end of lesson 1) and it's good to get it out of the way first.
Then start leaning CSS. You'll get the basics again, very quickly. But CSS is a minefield so expect to spend the rest of your life figuring it out.
Next up Action-script. Most people wouldn't agree with me, but bear with me. HTML and CSS aren't programming languages. Action-script is. And learning a programing language for the first time is difficult and tedious. The advantage Action-script has over most other languages is that the results are very visual. It's enjoyable to work with and you can sit back and take pride in your accomplishments at regular intervals. This isn't possible with server-side scripting languages or Javascript and there's a whole host of stuff you need to learn to get server side scripting up and running. You can't build space invaders in with PHP for example.
I've changed my thinking here. I would encourage beginners to ignore ActionScript and focus on Javascript. I still believe that being able to see stuff on screen quickly is a good motivator, but I would encourage people to look at canvas tag tutorials and frameworks. Javascript has come a long way since 2009, and is now the lingua franca of programming, so it's incredibly useful. My initial point about HTML and CSS not being programming languages still stands.
Then, you can start with your server side language. At the same time, you're going to have to figure out the database stuff. I recommend PHP and MySQL because it's free.
Again, I've changed my thinking here. I would encourage beginners to use Javascript on the backend (Node.js), and split their database learning between relational databases and noSql solutions such as Mongo.
Then.... learn your framework. Or better yet, roll your own. That's what I've been doing and it's supercharged my learning.
If you're getting into web development, You HAVE to know how those building blocks work. You don't have to be an expert in all the areas, but you should try to become an expert in at least one of them. If you start learning a framework before you get the fundamentals you'll be in a sticky middle ground where you don't understand why things don't work which will infuriate you, and anyone who has to work with you.
you should learn how to use framework because it would be helpfull for u in the future also it is easier to learn.
MVC will help you a lot .. trust me ... i was developing web project not using mvc and it is like mess ... (in the past there are no well know mvc and i never heard about it)
Short version: yes, and then some.
FWIW : This more generic answer may be of use to someone out there.
What: Frameworks take out tedium of using boiler-plate code again and again. They hide complexity and design issues under wizards and conventions. They also use special libraries, design patterns etc. in ways that are far from obvious to a beginner.
So using a framework is good for getting things done without knowing exactly how - like using an ATM without knowing the internals. You just add your code bits in certain places and things 'just work'.
HTML > CSS > Ruby > SQL > Rails/Javascript framework > Libraries would make for a good learning track. Rest you learn as you go along by being curious, hanging out on forums or as extended learning as need arises.
HOW: The problem starts the minute you step outside simple text-book examples (i.e. when you try to get it to do something even a bit different).
Decoding cryptic error messages when it seems like you've done everything right but things still don't work. Searching on error strings in forums may help out. Or just re-starting from scratch.
Reading up articles and books, videos, trial-and-error, hard-work, search-engines, stackoverflow/forums, local gurus, design articles, using libraries, source-code browsing are a good way to climb the learning curve gently and on a requirement basis.
Working-against-the-framework is the number one problem for beginners. Understanding what the framework expects is key to avoiding white-hair in this phase. Having enough insight to manually do what the framework automates may help reduce this second-guessing effort.
WHY: For more advanced debugging/design, it's good to know what the framework is doing under the hood esp. when things don't work as you planned. Initially you can take the help of local-gurus or forum gurus who've already done the hard work. Later as you go deeper you can take on more of that role. For example there's a "rebuilding rails" book which looks under the hood of Ruby on Rails.
Note: Some of the tips are oriented towards Ruby/Rails but you can easily substitute your favourite language/framework instead.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 8 years ago.
Improve this question
What are the popular (ok, popular is relative) web frameworks for the various flavours of LISP?
PLT Scheme features a built-in, continuation-based web server.
Update: PLT Scheme is now called Racket.
Hunchentoot is also quite widespread
What is Weblocks?
Weblocks is a continuations-based web framework written in Common Lisp.
http://common-lisp.net/project/cl-weblocks/
Most (perhaps all) of the well-known Common Lisp web frameworks have already been mentioned, so I'll just add some comments.
Hunchentoot is not a "web framework" in the sense that most people mean. It's an HTTP server (an extremely good one).
Drew Crampsie's "Lisp on Lines" looks extremely promising, but I'm not sure how far along it is. I've been waiting to hear an announcement.
Marco Baringer's UnCommon Web runs on many of the prominent CL implementions: Allegro CL, CMUCL, Clozure CL (formerly known as OpenMCL), GNU clisp, and SBCL. The only major one missing is LispWorks; I don't know if that means it hasn't been tested to work, or is known not to work, or what; but if it runs on all those other dialects, it's probably easy to make it run on any other.
For Clojure you can try Compojure.
Common Lisp
A lot of the usual suspects (Hunchentoot, UCW, LoL) have already been mentioned.
Franz makes available for Allegro Common Lisp (and ported to other Lisps):
at a lower level (handling HTTP requests yourself), AllegroServe.
at a higher level (more of a "framework"), WebActions.
Both are open source. I tend to use AllegroServe, factoring out utilities as I need them, but some people really like WebActions.
I used Araneida for quite some time, and I prefer its style to AllegroServe, but it hasn't been maintained since 2006.
I've searched quite extensively for a good web framework for Lisp, and I found them all to be somewhat inaccessible. The Architecture of UCW didn't seem very natural to me (I can't remember why; it's been a while since I looked into it), and KPAX isn't maintained anymore (I think).
Symbolic web looks very interesting, and I think Weblocks is the most interesting, but Weblocks isn't very well documented and can be pretty intimidating to the newcomer. SymbolicWeb was immature last time I looked, but it may have grow up some since then. The features page looks pretty good today.
There are different approaches you could take. If you want a purely lisp approach, then you could:
If you can read code proficiently and understand continuations, you might try Weblocks with a Hunchentoot backend (Weblocks has a dependency on Hunchentoot that hasn't been abstracted yet). There is supposed to be a real user manual out in a month or two, but as with any OSS project, such commitments are sketchy.
Similarly, you might try SymbolicWeb. [update: nevermind, the project is no more]
roll your own. Seriously - there's cl-who to help with HTML generation, there are javascript and json libraries available, usockets, elephant, cl-sql, hunchentoot, aserve, and lots of utility libraries that you could bake together.
If you are ok with a hybrid approach, this is something I'm experimenting with at the moment: I've written a Lisp JSON-RPC backend for Qooxdoo, so I can serve up pure javascript frontends through a superfast http server like Cherokee and let Cherokee farm out connections to as many backend json-rpc servers running in Lisp as I want. Very, very scalable. I'm far from figuring out the kinks and challenges, but it was pretty straight-forward to get working. the json library makes it stupid simple to get the backend working - Qooxdoo itself is actually harder, I think (but I'm not a JS developer, really).
I'm also going to be checking out WebActions from allegro, because there's a certain allure to the availability of paid support - not to mention that Allegro may be the best CL implementation available (His Kennyness uses it :-)).
UnCommonWeb (UCW) is often mentioned http://www.common-lisp.net/project/ucw/ -- it's not REST as is in en-vogue at the moment, more like Smalltalk's SeaSide (but then again, SeaSide is quite en-vogue).
LeftParen
Lisp-on-lines is a web application framework built on top of CLSQL and UCW and provides an application development model similar in many ways to Ruby on Rails. Right now it can be found at http://versions.tech.coop/lisp-on-lines/.
http://www.cliki.net/lisp-on-lines
http://kevin.casa.cavewallarts.com/LISP/LOL/lol.html
For Clojure you can try Webjure.
I just discovered a web framework called Clack for common lisp and found it quite easy to get started.
See http://clacklisp.org/
Quote from it's web site
"Clack is a web application environment for Common Lisp inspired by Python's WSGI and Ruby's Rack."
and caveman is a micro web framework based on Clack.
Another cool (yet far from "popular") thing to look at is SymbolicWeb -- http://groups.google.com/group/symbolicweb
Re: SymbolicWeb (and its exaggerated demise)
SymbolicWeb project page at Gitorious and SymbolicWeb article at Wikipedia. The Google Groups page is definitely dead (and unarchived?,) but the Gitorious tree shows checkins as recently as 29 April 2010. The project page also refers to "some running examples" being "occasionally available" at nostdal.org (which is unreachable as I write this, reinforcing the "occasionally" qualifier :-) .)
(Note: I'm not a SymbolicWeb user. I just tracked down the SymbolicWeb links while reading this thread.)
Restas is another web framework that has seen recent updates:
http://restas.lisper.ru/en/
Its overview
RESTAS is a Common Lisp web application framework. Its key features are:
RESTAS was developed to simplify development of web applications following the REST architectural style.
RESTAS is based on the Hunchentoot HTTP server. Web application development with RESTAS is in many ways simpler than with Hunchentoot, but some knowledge of Hunchentoot is required, at least about working with hunchentoot:*request* and hunchentoot:*reply*.
Request dispatch is based on a route system. The route system is the key concept of RESTAS and provides unique features not found in other web frameworks.
The other key RESTAS concept is its module system, which provides a simple and flexible mechanism for modularized code reuse.
Interactive development support. Any RESTAS code (such as the definition of a route, a module or a submodule) can be recompiled at any time when you work in SLIME and any changes you made can be immediately seen in the browser. No web server restart or other complicated actions are needed.
SLIME integration. The inner structure of a web application can be investigated with the standard "SLIME Inspector." For example, there is a "site map" and a simple code navigation with this map.
Easy to use, pure Lisp web application daemonization facility based on RESTAS and SBCL in Linux without the use of Screen or detachtty.
RESTAS is not an MVC framework, although it is not incompatible with the concept. From the MVC point of view, RESTAS provides the controller level. Nevertheless, RESTAS provides an effective and flexible way for separation of logic and representation, because it does not put any constraints on the structure of applications. Separation of model and controller can be effectively performed with Common Lisp facilities, and, hence, doesn't need any special support from the framework.
RESTAS does not come with a templating library. cl-closure-template and HTML-TEMPLATE are two good templating libraries that can be used with RESTAS.
This question is a bit old but I thought I'd share my recent discovery: the Hop language which is based on Scheme and is quite complete.
HOP is a multi-tier programming language for the Web 2.0 and the so-called diffuse Web. It is designed for programming interactive web applications in many fields such as multimedia (web galleries, music players, ...), ubiquitous and house automation (SmartPhones, personal appliance), mashups, office (web agendas, mail clients, ...), etc.
HOP features:
an extensive set of widgets for programming fancy and portable Web GUIs,
full compatibility with traditional Web technologies (JavaScript, HTML, CSS),
HTML5 support, a versatile Web server supporting HTTP/1.0 and HTTP/1.1,
a native multimedia support for enabling ubiquitous Web multimedia applications,
fast WebDAV level 1 support,
an optimizing native code compiler for server code,
an on-the-fly JavaScript compiler for client code,
an extensive set of libraries for the mail, calendars, databases, Telephony, ...
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 6 years ago.
Improve this question
Can you suggest some good MVC framework for perl -- one I am aware of is catalyst
The need is to be able to expose services on the perl infrastructure which can be called by Java/.Net applications seamlessly.
I'll tell you right now that Catalyst has by far the best reputation amongst Perl developers in terms of a rapid application development MVC framework.
In terms of "pure" MVC I'm not sure there are even that many "mature" or at least production-ready alternatives.
If Catalyst doesn't seem right to you, then you could build upon the lightweight framework CGI::Application to suit your needs or take a look at some of the lesser known MVC frameworks like PageKit and Maypole.
Since this old thread popped up, I will mention two exciting new additions to the Perl MVC world:
Dancer (CPAN) which is heavily influenced by Ruby's Sinatra, known for being very lightweight
Mojolicious (CPAN) which is written by the original developer of Catalyst to use what he learned there, it has no non-core dependencies, with very modern builtins (HTML5/CSS3/Websockets, JSON/XML parsers, its own UserAgent/templating engine)
(N.B. I have used Mojolicious more than Dancer, and as such if I missed some features of Dancer that I listed for Mojolicious then I apologize in advance)
Another alternative besides the ones already mentioned is Continuity; however, it is (as the name is meant to imply) continuation-based rather than MVC in the typical sense. Still, it’s worth mentioning because it is one of the better Perl web frameworks.
That said, I like Catalyst much better than any of the alternatives. And it’s still getting better all the time! The downside of that is that current preferred coding approaches continue to evolve at a fairly hurried clip – but for the last couple of versions, there has been strong emphasis on API compatibility, so the burden is now mostly mental rather than administrative. The upcoming port of the internals to Moose in particular is poised to provide some excellent benefits.
But the biggest argument in favour of Catalyst, IMO, is the Chained dispatch type. I have seen nothing like it in all of web-framework-dom, and it is a most excellent tool to keep your code as DRY as possible. This couples well with another great thing that Catalyst provides, namely uri_for – a method which takes a controller and a bunch of arguments and then constructs a URI that would dispatch to that place, which it returns. Together, these facilities mean that you can structure your URI space any way you deem right, yet at the same time can structure your controllers to avoid duplication of logic, and keep templates independent of the URI structure.
It’s just brilliant.
Seconding comments made by others: Catalyst (which more or less forked from Maypole) is by far and away the most complete and robust of them. There is a book by Jonathan Rockway that will certainly help you come to grips with it.
In addition to the 'Chained' dispatch type, the :Regex (and :LocalRegex) dispatch methods provide enormous flexibility. The latest app we've built here supports a lot of disparate-looking URLs through just a handful of subs using :LocalRegex.
I also particularly like the fact that you are not limited to a particular templating language or database. The mailing list (and the book) both have a preference for Template::Toolkit (as do I), and DBIx::Class (we continue to use Class::DBI), but you can use pretty much anything you like. Catalyst is marvelously agnostic that way.
Don't be put off by the fact Catalyst seems to require half of CPAN as dependencies. Once you get it up and running, it is a well-oiled machine. It has reached a level of maturity now that once you come to grips with it, you find it 'fades into the background'. You spend your time solving business needs, not fighting with the tools you use.
It does what it says on the tin. Catalyst++
Been playing with Squatting the last few days and I have to say it looks very promising and been fun to use.
Its a micro webframework (or web microframework ;-) and is heavily influenced by Camping which is written in Ruby.
NB. Squatting (& Camping) don't have model components baked into the framework. Here's the authors comments on models... "Models? The whole world is your model. ;-) I've always been ambivalent about defining policy here. Use whatever works for you"
There is also CGI::Application, which is more like the guts of a framework. It helps a person to write basic CGI's and glue bits on to it to make it as custom as they like. So you can have it use hardly any modules, or just about everyone under the sun.
Catalyst is the way to go. There is also Jifty, but (last time I looked), it had terrible documentation.
If you are already aware of Catalyst, then I recommend focusing on it. It is mature, well-documented, and has a very large user-base, community, and collection of plug-ins.
For your problem I would take a look into Jifty::Plugin::REST which allows access to models and actions using various formats.
Let me just say that Jifty doesn't have terrible documentation. However, most of included documentation is API documentation, but there is very low-noise mailing list which has useful tips and links to applications.
Wiki at http://jifty.org/ is another resource which has useful bits.
If your goal is to make video store (my favorite benchmark for 4GLs and CRUD frameworks) in afternoon, it's really worth a look!
Another options is Gantry when used in conjunction with the BigTop module it can reduce the time it takes to build simple CRUD sites.
There is also Clearpress which I can recommend as a useful database backed application. It needs fewer dependencies than Catalyst. We have written a few large applications with it, and I run a badminton ladder website using it.
I have built some applications with Kelp, it's easy to learn and very helpful.