4 ms·
Let me break this down into parts. I'll address the web space specifically. For reference, I've had over a year of clojure development experience now. Some of t
by tensor 15y ago
Let me break this down into parts. I'll address the web space specifically. For reference, I've had over a year of clojure development experience now. Some of these statements are from my own perspective, others from complete newcomers to clojure that I've talked to or worked with:
1) Most of the time I resort to reading the actual source.
2) There are many libraries which have native clojure documentation on each function, but lack a website summarizing it.
3) Trying to figure out how all the various web components fit together is very time consuming.
3.1) How do ring sessions handle security? (they default to a memory store, but you need to dig to find this, I don't know if the cookie store uses encyrption)
3.2) ClojureQL is still in heavy development, but the documentation is lacking answers to many frequently asked questions. EG:
3.3) How does one execute a series of statements in a transaction?
3.4) How does one retrieve the id of the record just inserted?
There are answers. For the first, you can use clojure.java.jdbc, or clojure.contrib.sql, given some constraints. For the second, you can't, but the latest dev snapshot can.
3.5) How do you execute arbitrary SQL? (you can in batch with jdbc, but not all statements work in batch)
3.6) session expiry, a critical feature. But you need to dig to find hozumi/session-expiry. Also, it doesn't work with sandbar's stateful sessions in my experience. All not documented.
3.7) security restrictions are another huge problem for clojure web frameworks. Sandbar's are ok, but still limited and not particularly performant. I'll try to get some code released soon on this front.
3.8) Understanding how ring and it's requests work is a challenge. There should probably be a small book chapter explaining the architecture of this. I understand it, but it took a lot of reading on mailing lists and ultimately the source code to figure it out.
4) Beyond documentation. Clojure web frameworks are based on composing many small components. This is great and has many strengths beyond those of other frameworks. However, a lot of users are looking for a turnkey "do this, do that" solution. They want to know the best standard practice. This is process, something that gives strengths to frameworks like Ruby on Rails.
While I would not suggest abandoning the composability of clojure web frameworks, having a standardized large scale framework with standardized process would go a long way to getting more widespread adoption.
For example, a framework with recommendations for large scale code organisation like model view controller, or similar functional equivalents, along with recommendations for standardized modules and coding practices.
Webnoir is still too much of a micro framework to handle these needs. We don't need to abandon flexibility and composability. However, there needs to be a manual of best practices along with code that makes it easy to use for common web app development, all details included.
Above all, a central resource tying all these points together is what is needed. I too want to help with this.