I'm having trouble understanding the point of clojure's Noir library. It seems to be a framework written on top of compojure that renames defroute to defpage and calls it a day. Obviously an unfair simplification, but what exactly does Noir bring to the table? Why would I use Noir instead of plain compojure+hiccup?
EDIT/UPDATE:
Noir is deprecated, interesting write up here: http://blog.raynes.me/blog/2012/12/13/moving-away-from-noir/.
From the author of Noir himself:
Noir isn't really a replacement for [compojure and hiccup], more of an abstraction over them. It was born out of seeing how a real web-app evolved and what was missing from the ring/compojure/hiccup stack as I built http://www.typewire.io. Also, as I mentioned in one of the other comments, I hope that it will serve as the single "package" to start with web development in Clojure, instead of having to try and cobble it together from the pieces that are out there now. By controlling all of it, I can create a much more cohesive and well defined story for helping people get started. I can also share what I've learned about maintaining websites in Clojure and hopefully encourage patterns that avoid some of the pits I fell into.
(emphasis mine)
Noir, the framework has been deprecated by Noir maintener himself.
It suggests to use Compojure and lib-noir :
For new websites, please use Compojure and lib-noir. This is pretty much just as batteries included as Noir itself ever was! You just have to learn how to write routes with Compojure. It’s easy and just as concise as it was in Noir. You don’t have to use ring-jetty-adapter and stuff, just use the lein-ring plugin to start your server. Also, if you took advantage of Noir including hiccup by default, you’ll have to have an explicit dependency on it now. No biggy, right? Right!
Compojure
lib-noir
Compojure is a small framework that generates Ring request/response handlers, where handlers are chosen based on routes you define.
Noir adds functionality for session handling, cookies, templates and partials, an easier way to generate responses, form validation, route filters, encrypted passwords, JSON (de-)serialising and custom status pages. In other words, Noir combines Compojure, Hiccup, and a bunch of other clever stuff in one package.
You can always check the API on the webnoir.org website. There is a lot of added functionality besides defpage.
Related
I am trying figure out which one (Pedestal, Hoplon, Bidi) should i use? I didn't find any good article in the Internet which help me with this choice.
From https://github.com/juxt/bidi i can read Pedestal is isomorphic, but Bidi is also cljs. What is it mean? What is the difference?
I found compojure is too simply. I can't even generate URLs in HTML templates. I started looking something else. I found also route-one (library to generate URLs working with compojure), but i guess soon i will discover i need something more then compojure have again.
My intuition say me to choose between: Pedestal, Hoplon and Bidi.
What i need:
I want have independent business model architecture like
http://blog.8thlight.com/uncle-bob/2012/08/13/the-clean-architecture.html
http://blog.find-method.de/index.php?/archives/209-Dependency-inversion-in-Clojure.html
I don't want depend this part of code with any framework. Less dependency is better.
On next stage i want inject this model business into something like bridge, which will be the connector with user interface. It can be time for framework or additional libraries.
And at least i want create frontend user interface as website. It will be dynamic content with ClojureScript or mayby static. I don't know. I have to thing about both.
What i found out in Clojure i really like conception of building my own set of libraries based on my preferences. But i don't want write my own code to use things like generate URLs for routes. So mayby i should also consider route-one?
Please write something clever what help me choose one or complicate my live with some other option to choose :)
https://github.com/juxt/bidi
https://github.com/pedestal/pedestal
https://github.com/tailrecursion/hoplon
https://github.com/clojurewerkz/route-one
This is an ancient question, and I don't pretend to have an answer (much less "the" answer). But I'm googling for some of the same basic pieces tonight, and my search results came back with this response.
So I figured I'd jot down notes about my [very] limited understanding here.
Bidi seems awesome. From what I've seen, juxt produces very high quality software. For places where I need REST-style interface routing (which includes sending related routes back), this is my current GOTO choice.
Pedestal - also awesome. But it seems to be a very different use case. Routing
is a very small subset here (and they've tried multiple approaches to come up with a really good set of options). This seems to be more of a fairly low-level full-featured server-side library for integrating the code you care about with the underlying server pieces that you don't.
To be honest, I'm not sure Pedestal's routing libraries really support the reverse endpoints you have to have for REST. I think they almost definitely do, but I'm not positive. My use cases have all been about their interceptor chaining abstraction, which is mind-blowingly awesome.
Hoplon - I haven't looked at this in 2-3 years. At the time, it seemed like a big, bold, high-level kitchen-sink framework that's somewhere in the same ballpark as Ruby On Rails (although I think there are also front-end components). I've been writing API end-points, and this didn't seem like a good fit at the time. It deserves more attention than I gave it.
route-one - I hadn't heard about it before this question. I've gotten good impressions from everything that I have used from clojurewerkz, but that usage has been very light.
I'm fairly new to clojure/compojure, but really love it. Naturally, started my exploration with Noir stack. Have written a POC app. Then, discovered Liberator -- makes a whole lot of sense. Just wondering, if anybody has ever migrated Noir applications to Liberator before. Any references to articles/blogs that cover this would be highly appreciated.
The goal for Noir and Liberator is slightly different.
In simple words, you would use Noir to create website or web applications, and Liberator to create APIs, by exposing your resources for RESTful access. So to answer your main question, you would not really migrate from Noir to Liberator.
Also nowadays, Noir has actually been deprecated for compojure+lib-noir
Just in case, the main frameworks to build web applications these days in Clojure would be:
Luminus
Pedestal,
(and to a lesser degree) ClojureScriptOne
(and as stated above) pure compojure + libnoir
I was learning most clojure/compojure from the the book http://pragprog.com/book/dswdcloj/web-development-with-clojure which is still in beta. Seems that it's out of date before it even published. The Pedestal seems to be very very interesting and exciting. Though, what do people think, I know it's hard to predict, but what is a possibility of Pedestal becoming a next defacto standard replacing compojure+libnoir? Just have very scarce resources, and trying to make correct choices early in the game. Making simple decision is difficult these days.
Note: I'm a backend (Java) developer by trade and work in Clojure in my spare time, so forgive me for my ignorance.
I'm trying to get my head around Clojurescript and how it could potentially fit in with projects I'm working on, or plan to work on in the future. As I've grown up with the "classic" web development mindset (e.g. Clojure running the backend, distributing data to the frontend via JSON to be processed in JS or returning a HTML page for the browser to render), I'm having trouble trying to understand how Clojurescript might make things better than this model.
Could anyone explain to me what the general approach to Clojurescript/Clojure development would be, seeing as the "Clojurescript One" project moniker signifies that application development will be unified under one language (as such)
What tasks would normally be done in the Clojurescript portion of the application?
What tasks would normally be done in the Clojure (e.g. backend) portion of the application?
Any help would be appreciated, or if anyone can point me towards some diagrams or explanations or anything - that would be great too!
I think Clojure/ClojureScript applications will be structured very similarly to X backend technology + JavaScript.
One big benefit with architecting applications with Clojure and ClojureScript - a richer data format than JSON (you can represent hash-maps and sets with arbitrary keys) without losing compactness.
JavaScript is a fine, fine language but ClojureScript offers quite a few benefits. It's semantically simpler (functional), ships with a rich standard library, a robust battle tested application library (Google Closure), and all the benefits you get from the tasteful application of syntactic abstraction via macros.
That said, it's still very much alpha software and the tooling still needs a lot of work.
A bit of background about me, I have developed with Clojurescript, JQuery, Vaadin, Servlets, JSP, and many other web technologies.
1) Clojurescript is much harder to learn than any other web technology I have used as you need, Java, Clojure, Closure (with an s ;), Closure Lib, and Closurescript specific knowledge.
2) Clojurescript doesn't make sense for a small app. It only makes sense when you will have ALOT of client side processing
3) Clojurescript's only use as far as I see is as a better javascript (which is why it is better suited to larger apps) as the minifier part of Clojurescript is available for javascript too
4) Only the client end would be written in Javascript, the server would be in Clojure/Java servlets
Maybe Ganelon micro-framework (which incidentally I am author of) will suit your needs - the execution model is similiar to Vaadin's: server-side Clojure code pushes UI updates to the browser through AJAX/JavaScript, but we don't store application state in session by default.
The demo and docs are available at http://ganelon.tomeklipski.com/
For me, clojure and clojurescript offers cleaner code than mixed stack. There is only one language to think of and code is quite easy to read.
At the backend clojure does things that java usually would do. Input validation, saving to database and above all, implementing business logic. Our backend also validates incoming / outgoing data by types using prismatic schemas.
Frontend in short: We get pretty code using ClojureScript and it is fast to write. We are using ClojureScript version of material-ui when writing UI components. We have to write less code when compared to the JavaScript and I find our UI component code to be easier to read than JavaScript counterpart. One of the main reasons is shorter closing tags and less noise by coding language. Development with ClojureScript is quite fast.
Of course ClojureScript is used for simple imput validation like RegExp for phone numbers etc.
One of the disadvantages of clojure which you have probably noticed is long lines after giving proper names to the functions. I havent found silver bullet how to cope with that.
As dnolen said: ClojureScript is still developing. It is way better now than it was 6 months ago, so you'll have to keep checking its maturity now and then.
Lots of languages have microframeworks for writing very tiny websites or web services, such as Flask for Python, or Sinatra for Ruby. On Squeak, there doesn't seem to be any equivalent; Iliad, Seaside, and AIDA are all very heavy for just having a little service. What's the preferred way to accomplish this? Directly injecting a hanlder into Comanche or Swazoo?
"In this particular case, I literally have three URLs that need to do stuff via HTTP POST; that's it."
For really simple cases, you can just register with (or subclass) Kom's HttpService like so (from the class comment, see for more info/options):
(HttpService on: 8080 named: 'Example Http Service')
onRequestDo: [ :httpRequest | SomeGlobal processRequest: httpRequest ];
start
You can also use teapot. Teapot is micro web framework on top of the Zinc HTTP components, that focuses on simplicity and ease of use. It's under 500 lines of code, not counting the tests.
Teapot on
GET: '/hi' -> 'Bonjour!';
GET: '/hi/<user>' -> [:req | 'Hello ', (req at: #user)];
GET: '/say/hi/*' -> (Send message: #greet: to: greeter);
start.
(ZnEasy get: 'http://localhost:1701/hi/user1') entity string. "Hello user1"
There are available mustache templates, output transformers, before filters. The framework is well documented.
I would like to share what I think is more up-to-date information (as of end of 2012).
Zinc Components
Currently in Pharo 1.4/2.0 the de-facto standard for HTTP client/server seems to be the Zinc HTTP Components. And the latest Seaside version (3.0) switched to Zinc as well.
You can of course use Zinc directly to implement web-services or serve web-pages.
Take a look particularly at classes ZnServer and search for classes like Zn*Delegate (like ZnDefaultServerDelegate or ZnStaticFileServerDelegate)
Seaside REST
Latest versions of Seaside include support for RESTful web-services. This can be used to implement web-services or serve web-pages. It's pretty straightforward.
For more information look at the "REST Services" chapter of the online Seaside book. This chapter centers about implementing web-services, but it works for web-pages as well.
Ratpack
I have also been told about Ratpack, a sinatra-like web-framework developed by Tim Felgentreff. There are two repositories. I think the github one is more recent. See here:
http://ss3.gemstone.com/ss/RatPack.html
https://github.com/timfel/ratpack
This information comes from a similar question I posted recently.
You can subclass a SwazooSite in Swazoo for such a micro website, but I think you will soon end needing more functionality, so starting directly on one of those three frameworks are better bet long-term.
That they are heavy is maybe just an impression and lack of better documentation of usage for such simple websites. Also, if you look at the framework as blackbox, which is complex internally but simple externally, then I'd say all Smalltalk web frameworks are quite simple comparing to other web frameworks.
I've heard of two Clojure based web application frameworks: Webjure and Compojure. Can someone let me know which is better?
Now you can add Ring to the list. All of these frameworks are very new and likely to evolve (or die) quickly, but Compojure does seem to be the most actively developed based on the past 6 months or so.
"Better" is too subjective a question to get a definitive answer to. Try them all and see what works.
Compojure has been working very well for me so far. I like the simplicity of the design, the flexibility and the fact that it encourages a nice idiomatic functional style.
Sample server:
(use 'compojure)
(defroutes my-app
(GET "/index.html"
(html
[:h1 "Hello World!!"]
[:body "This is some text"]))
(ANY "*"
[404 "Page not found"]))
(run-server {:port 80}
"/*" (servlet my-app))
Note that Compojure uses Ring internally.
I second Rayne's recommendation on Moustache.
Right now, we are using Ring (base layer, middleware), Moustache (routing), Hiccup (html generation). We just began using Compass for CSS (http://compass-style.org/). So far, I'm happy with this collection of small libraries rather than a big "complete stack" framework (Django, Rails, ect...).
Now, there is also a new one named Noir build on top of compojure. Really recommended, especially with Heroku.
Compojure seems to be getting the most buzz right now. Not necessarily indicative of quality, but the one with the most eyes will probably evolve the fastest.
There is also Moustache, which is what I use in TryClojure, along with Ring. It's pretty awesome.
Compojure is based on Ring, which is a low-level framework that doesn't attempt to hide much of HTTP. It's similar to WSGI (Python) or Rack (Ruby). Ring has a concept of middleware, small pieces of code that can do something meaningful with an HTTP request and/or response, such as dump header infos, manage cookies etc. Compojure is a higher-level framework, somewhat similar to Ruby's Sinatra. Its aim is to provide a convenient API (or DSL, if you prefer) for most tasks a Web app developer faces. It's usually used together with an HTML generation library, such as Hiccup.
I haven't heard much about Webjure in the last few months, I'm not sure it's in active development (but I'd be interested to find out more). It precedes Ring, AFAICT, which seems to have become somewhat of a standard for Clojure Web frameworks.
I've been building a project for my own use using Compojure and it has worked out great. It doesn't really get in the way very much and lets you focus on what's important, your problem domain. The project is about 1100 lines of clojure just to give you an idea of the size.