4 ms·

> For backend web development Rails is still miles ahead of any Clojure workflow. In what way?

akjetma 11y ago
'Lack' of frameworks. I always think it's kind of funny when starting a new Clojure web project, I have to explicitly insert a middleware for parsing parameter strings into a Clojure data structure, and then another middleware for transforming the string keys in that structure into keywords. There are just a bunch of things that don't magically work for you. That said, I really enjoy Clojure and appreciate/understand the high configurability.
- AlwaysBCoding 11y ago
  Oh man, and having to manually configure your server logs just so you can see what requests are being made and where errors are popping up vs. just tailing log/development.txt in Rails...
- sveri 11y ago
  Hi, author of closp (https://github.com/sveri/closp https://github.com/sveri/closp). TLDR; Yes, clojure is behind in regards of web development, but it is not as bad as you said. There is active work done in this area. I totally agree with what you said. It is a general understanding in the clojure community that you compose libraries to get things done. However, for web development that still means a lot of repitition, thats why I created the closp template. It is based on luminus (http://www.luminusweb.net/ http://www.luminusweb.net/) which is a lighter "framework" with more options. My idea was to provide one way with sensible defaults to get started in doing web stuff in clojure. I still work regularly on it and would be happy about contributions / feature requests. Whereas regularly means in terms of months as I do this all in my spare time. Also I am quite active in the clojure community and I know that luminus is not shunned, but instead it also receives improvements and releases regularly. Also the author of luminus works professionally with clojure and with luminus. And I have to admit, that luminus has the far superior documentation, he has done a good job on it I think.
- yogthos 11y ago
  These are precisely the kinds of things that Luminus http://www.luminusweb.net/ http://www.luminusweb.net/ addresses. The template generates a project with all these things configured with reasonable defaults for a typical application. Luminus will also setup things like a logging configuration, authentication, databases, Swagger API, etc. I think the fact that these things aren't magically is a big plus. You can use the defaults, but you can trivially customize the middleware stack for your specific needs. Another thing to note is that a lot of the stuff that traditional frameworks do is geared towards doing presentation on the server. Modern apps tend to do presentation on the client, and the server primarily provides a set of stateless services for the client to fetch the data that it needs. With this approach, you don't really need a complex server framework in the first place.
- retrogradeorbit 11y ago
  Use destructuring to pull the needed values out of the ring request. For example: (defn login [{{:keys [email password]} :params session :session}] ...) Also remember as well as the :keys special form you have :strs and :syms. https://gist.github.com/john2x/e1dca953548bfdfb9844 https://gist.github.com/john2x/e1dca953548bfdfb9844
jraines 11y ago
I think most are related to easiness, and so not recognized as an advantage by many Clojure acolytes (see: Rich Hickey's Simple Made Easy talk). Others are a consequence of shared state; also not recognized as a positive in Clojureland (rightfully so in most cases). Here's my list: - Database migrations - Fast TDD (for some sub-Gary Bernhardt definition of fast) with access to the app environment. - content negotiation - Authentication with Devise and Omniauth - Easy built-in support for caching - Easy built-in support for background queue systems - Easy support for one-off or occasional scripts with access to the whole app environment (rake tasks) - Pry (yes, Clojure has awesome REPL powers, but Pry is so easy to use, and you have access to the whole app environment (no loading / switching namespaces or abuse of user.clj)) There's probably some solution to each of these. But all require you to find/know the options, and be able to evaluate which is best for you ("all REAL devs . . ." sure, sure). For Rails, all of these are available to you in the Rails Guides, except for Devise+Omniauth, which has an extensive wiki and tons of StackOverflow answers.
- weavejester 11y ago
  Thanks, that's a good list, and I see the problem. Out of interest, what makes Pry easier to use? I'm not sure I understand the comment about having access to the whole app environment. In the Clojure REPL you do as well...?
  - jraines 11y ago
    When I reflect on the ease of use question, I realize most of my frustrations with the Clojure REPL have actually been with trying to use it within an editor (Vim, Emacs, and Atom so far). And particularly with getting a ClojureScript REPL through those tools. That's not something I try to do with Pry, being content to use it from the terminal, so maybe not a totally fair comparison. The app environment thing is mostly about having to switch between a lot of namespaces and/or to make sure they're all loaded upon starting the REPL. With Rails+Pry, you can work with any class in your app immediately. It also lets you put breakpoints in your code, where executing the code in a running process throws you into a REPL at that point, with all the local context up to that point of execution. Also, if you make code changes, you simply type "reload!" in the REPL and everything's up to date. I have a bookmark to read Stuart Sierra's post about his workflow to try to get a grip on how to come close to something like that in Clojure. And it can do a lot more great stuff, too: https://www.youtube.com/watch?v=4hfMUP5iTq8 https://www.youtube.com/watch?v=4hfMUP5iTq8 Oh and by the way -- thanks for all of your OSS work in the Clojure world! Especially taking the extra step of providing good docs.

'Lack' of frameworks. I always think it's kind of funny when starting a new Clojure web project, I have to explicitly insert a middleware for parsing parameter strings into a Clojure data structure, and then another middleware for transforming the string keys in that structure into keywords. There are just a bunch of things that don't magically work for you. That said, I really enjoy Clojure and appreciate/understand the high configurability.

AlwaysBCoding 11y ago
Oh man, and having to manually configure your server logs just so you can see what requests are being made and where errors are popping up vs. just tailing log/development.txt in Rails...
sveri 11y ago
Hi, author of closp (https://github.com/sveri/closp https://github.com/sveri/closp). TLDR; Yes, clojure is behind in regards of web development, but it is not as bad as you said. There is active work done in this area. I totally agree with what you said. It is a general understanding in the clojure community that you compose libraries to get things done. However, for web development that still means a lot of repitition, thats why I created the closp template. It is based on luminus (http://www.luminusweb.net/ http://www.luminusweb.net/) which is a lighter "framework" with more options. My idea was to provide one way with sensible defaults to get started in doing web stuff in clojure. I still work regularly on it and would be happy about contributions / feature requests. Whereas regularly means in terms of months as I do this all in my spare time. Also I am quite active in the clojure community and I know that luminus is not shunned, but instead it also receives improvements and releases regularly. Also the author of luminus works professionally with clojure and with luminus. And I have to admit, that luminus has the far superior documentation, he has done a good job on it I think.
yogthos 11y ago
These are precisely the kinds of things that Luminus http://www.luminusweb.net/ http://www.luminusweb.net/ addresses. The template generates a project with all these things configured with reasonable defaults for a typical application. Luminus will also setup things like a logging configuration, authentication, databases, Swagger API, etc. I think the fact that these things aren't magically is a big plus. You can use the defaults, but you can trivially customize the middleware stack for your specific needs. Another thing to note is that a lot of the stuff that traditional frameworks do is geared towards doing presentation on the server. Modern apps tend to do presentation on the client, and the server primarily provides a set of stateless services for the client to fetch the data that it needs. With this approach, you don't really need a complex server framework in the first place.
retrogradeorbit 11y ago
Use destructuring to pull the needed values out of the ring request. For example: (defn login [{{:keys [email password]} :params session :session}] ...) Also remember as well as the :keys special form you have :strs and :syms. https://gist.github.com/john2x/e1dca953548bfdfb9844 https://gist.github.com/john2x/e1dca953548bfdfb9844

jraines 11y ago

I think most are related to easiness, and so not recognized as an advantage by many Clojure acolytes (see: Rich Hickey's Simple Made Easy talk). Others are a consequence of shared state; also not recognized as a positive in Clojureland (rightfully so in most cases). Here's my list: - Database migrations - Fast TDD (for some sub-Gary Bernhardt definition of fast) with access to the app environment. - content negotiation - Authentication with Devise and Omniauth - Easy built-in support for caching - Easy built-in support for background queue systems - Easy support for one-off or occasional scripts with access to the whole app environment (rake tasks) - Pry (yes, Clojure has awesome REPL powers, but Pry is so easy to use, and you have access to the whole app environment (no loading / switching namespaces or abuse of user.clj)) There's probably some solution to each of these. But all require you to find/know the options, and be able to evaluate which is best for you ("all REAL devs . . ." sure, sure). For Rails, all of these are available to you in the Rails Guides, except for Devise+Omniauth, which has an extensive wiki and tons of StackOverflow answers.

weavejester 11y ago
Thanks, that's a good list, and I see the problem. Out of interest, what makes Pry easier to use? I'm not sure I understand the comment about having access to the whole app environment. In the Clojure REPL you do as well...?
- jraines 11y ago
  When I reflect on the ease of use question, I realize most of my frustrations with the Clojure REPL have actually been with trying to use it within an editor (Vim, Emacs, and Atom so far). And particularly with getting a ClojureScript REPL through those tools. That's not something I try to do with Pry, being content to use it from the terminal, so maybe not a totally fair comparison. The app environment thing is mostly about having to switch between a lot of namespaces and/or to make sure they're all loaded upon starting the REPL. With Rails+Pry, you can work with any class in your app immediately. It also lets you put breakpoints in your code, where executing the code in a running process throws you into a REPL at that point, with all the local context up to that point of execution. Also, if you make code changes, you simply type "reload!" in the REPL and everything's up to date. I have a bookmark to read Stuart Sierra's post about his workflow to try to get a grip on how to come close to something like that in Clojure. And it can do a lot more great stuff, too: https://www.youtube.com/watch?v=4hfMUP5iTq8 https://www.youtube.com/watch?v=4hfMUP5iTq8 Oh and by the way -- thanks for all of your OSS work in the Clojure world! Especially taking the extra step of providing good docs.