It seems much easier to use the same language when using a Lisp dialect compared to for instance Java, which would be a lot more verbose, but it is also done this way to separate logic from presentation, and because it's (supposedly) easier for front-end developers. Coming from non-CL frameworks, it was natural for me to choose a template framework for my small (and now outdated) tutorial on writing a blog in CL (http://goo.gl/YHCw).
However, I'm wondering if anyone has any experience developing web applications using a Lisp-dialect for generating the HTML (as Noire and the example in Practical Common Lisp), and if this is scalable to a team where front-end developers might not be used to or familiar with Lisp.
The syntax seems easy on the eyes, so perhaps it's not such a big problem once they get over the unfamiliarity.
Even when using simple template languages I have experienced the I didn't understand those funny bits in the HTML so I have removed them far too many times.
In Clojure, Enlive (https://github.com/cgrand/enlive) is a better solution because the HTML remains as HTML.
For example, one might write a page like:
(defn user-settings [user]
(breadcrumbs (link home) (link settings))
Hiccup tends to lend itself toward user interfaces that are uniform and predictable, with repeatable elements. Think Facebook or Github, for instance.
You can get around this in Enlive and other HTML-based templating methods by taking a hybrid approach. The layout HTML is written by a designer, but all the tedious repeatable elements are written by programmers in helper functions, or factored out into dozens of smaller templates.
I'm not sure I like this approach, as it (a) glues together several different methods for generating HTML, (b) encourages people to write the HTML around the page design, rather than treating HTML as purely semantic markup.
I admit to being something of a purist when it comes to HTML. I'd prefer to keep the style and design of the page out of my HTML as much as possible; idiomatic HTML should be semantic markup, whilst the design of the page should be defined in CSS.
In short, step 1 Hiccup, step 2 ???, step 3 profit!, step 4 Enlive.
(Also: dealing with browser induced styling edge cases while you're trying to focus on substantial features is every programmers hell.)
(Edit: I'm a compojure/hiccup fanboy in my spare time, but during the day I work at a large company who can't hire enough programmers.)
However, I'm a HTML purist at heart. I believe HTML should be semantic markup, and that the page design should be independent of the HTML generated, whenever possible. Ideally, it's the CSS that should determine the page layout and style.
I also work for a company that produces very uniform web interfaces, and where the developers significantly outnumber the UX guys. Hiccup would work very well in this environment, but perhaps not so well in an environment with many designers :)
Also, I really love html functions as opposed to JQuery-esque template filling. It's cleaner and more flexible to me.
It is not a significant obstacle.
See this Stackoverflow question... CL-WHO-like HTML templating for other languages? (http://stackoverflow.com/questions/671572/cl-who-like-html-t...) which provides some examples in other languages.
One question: form rendering, validation and handling are the most important as well as the most annoying things you have to do while writing a web application. Do you plan to incorporate something for that into the framework?
It looks like Noir uses a custom "lein run" command to start the server. Have you considered using the lein-ring plugin, instead?
Edit: and now it is :D
* SHA-x is not an "encryption" algorithm, it's merely a cryptographically secure, one-way hash. The function name and the documentation are thus misleading.
* You shouldn't use SHA-x or MD5, etc. for password hashing anyway, because they are just way too fast! You should use BCrypt for password hashing.
I can submit patches if you wish :)
Sorry if these seem like dumb questions, just trying to learn.
BCrypt is a very good algorithm for hashing passwords because it's very slow (compared to SHA-x) and thus are extremely time consuming for an attacker. BCrypt also allows to incorporate a "work-factor" which makes the hashing even slower; that allows us to choose a higher work factor when more powerful computers become commonplace.
There are a lot of articles online that discuss this subject.
Disclaimer: I'm absolutely not a security professional.
I was also confused by these frameworks (e.g., Django) that ask you for a secret key and I thought that the secret key was a site-wide salt. Fortunately, they knew better than me ;-)
Noir looks very good. Keep up the good work and let me know if you need any help ;)
In a nutshell: Make small simple things even if thats ends up beeing a bit more verbose then if you would have built it as one thing. If time shows that a set of librarys works very nicly together then you can write something new that combines these in a nice way.
This is what the Noir does it just pulls together some librarys and delivers them in a nice package.
I know Clojure doesn't support first-class continuations, but does anyone know whether is it possible to use Clojure Noir to program in this style?
I agree that learning Haskell as a prelude to learning Scala and Clojure might not be a bad idea (I blogged about this a few days ago).
Still, looks very interesting.
It's like someone showing off a new garbage collection library built in C. The problem's been solved. Show me something new.
However, in my rather biased opinion, many of the core Clojure web development libraries already exceed those built for Ruby, and certainly vastly exceed those that existed when RoR was first released.
For me, the most interesting part of libraries like Noir is how much they use existing libraries. It indicates we're doing something very right with regard to modularity.
Clojure's been popular in the hacker community for a good 2 years now. That's a weak argument.
And Clojure has been known for a good two years now, but I would not have said Clojure was popular two years ago. It didn't have a lot of regular users, which is what you're observing when you say people aren't solving "real problems" in it. I'm not sure I'd even say Clojure is popular today. I'd say it's still roughly where Ruby was in 2004 — lots of excitement, but still lots of growing to do.
When Rails came out it solved all kinds of new problems. For one, by using metaprogramming a whole bunch of files were eliminated. As soon as Rails came out I was much more productive than I was with Tapestry or Wicket. Not so with Clojure.
Just because it doesn't necessarily better solve your class of problems doesn't mean it's unsuitable for other people's.
I'm impressed by results
The reason why people want Clojure on the web could be (or "How Clojure can make your life easier for webapplications):
1. Use FP in the Web (I mean general imutability not closures)
2. Safe and easy concurency
3. Tons of java librarys for general stuff that you might do
4. Very powerful meta programming. Rails has shown this to be a win and with Clojure much more is possible.
I've been in the Clojure community for some time and the real "boom" of Webapplications in Clojure has only really lifted in the last year. I think its pretty impressiv how the Webstack developed in that time.
Level of confidence instilled in me because of this: 0%
Chance I'll come back later to check it out: 0%
Probability I'll go visit Enlive right now: 100%
Can't help but suspect you're choking on your own dog food here. Or crapping out a corn-studded loaf, take your pick.