5 ms·

I've used Luminus to fill that space, and I gotta say I don't think that's the best way to go for Clojure. Getting started with Luminus was fine, but it was of

I've used Luminus to fill that space, and I gotta say I don't think that's the best way to go for Clojure. Getting started with Luminus was fine, but it was often very confusing and I didn't understand a lot, whereas when I added things as I needed them and checked out a couple libraries, I had a lot easier time debugging what was wrong. What's going to make Coast different?

dvcrn 7y ago
IMO languages like Clojure (or Go) don’t need a fully powered batteries included web framework like Rails or Django. The approach to pick together what you actually need (router, db bits and pieces, etc) with composable libraries works really great
- goostavos 7y ago
  After having gone through this, I now disagree. There are a vast many things in which I am not an expert. The pick and choose / compose your libraries / lego approach sounds great until your trying to weigh different options (of which none seem to have a wide enough install base to be truly battle tested). Is buddy/buddy-auth the way to go for security? Or is it Friend? The former seems to receive more recommendations as of late, whereas the latter has more activity on github. These are not the problems I want to be solving when building something. I love the language, but the quality of Clojure's web ecosystem is... questionable. If I were to build another webapp in Clojure, I think I'd just use something widely installed like Jersey for actually interfacing with the outside world. It'll be crufty Java, but it has nice things like StackOverflow activity, massive docs, giant userbase, etc.. etc..
  - blunte 7y ago
    You express exactly what has kept me from doing webdev with Clojure, despite my (now perhaps irrational) love for the language. I will learn whichever language allows me to get my site/app done as quickly as possible at first. Later after I have refined and refactored enough to know what's up... then I may decide to change. Nextjs (despite the javascript), Rails (Ruby is great!... not Clojure, but pretty good), Django (Python is low-pain, low-effort), etc. are all easy quick ways to actually get something done BEFORE you really know what you're doing. This is critically important for those of us who don't spend all our time doing public-facing web apps.
    - Scarbutt 7y ago
      As someone who tries to use Clojure everywhere I can, its very hard to beat Rails for pushing out a webapp (many long Clojure timers share this opinion). Clojure shines for web services that require lots of data processing in the server and for integrating with parts of the Java ecosystem.
      - blunte 7y ago
        I have not investigated Coast yet. I know it aims to be a Rails for Clojure... maybe it is, and maybe it would meet my needs. But given the incredible power and expressiveness of Clojure, I find no reason to believe that the best rapid web development framework could be developed in Clojure if the right motivated people attempted to do so. I don't know how many people (Plataformatec?) were behind Phoenix, but even in its early versions it was comparable to Rails. In some ways, it was even better. There seem to be two obstacles to doing this in Clojure. The first is that people who actually know enough about Clojure to do this are actually very busy (happily) doing Clojure for work. They don't have the personal need to build a Rails for Clojure. The second is that those who would be capable already know how to pick and choose the libraries and build their own (even better, more suited for the purpose) ad-hoc frameworks for their projects. I suppose it could be a curse of the power of Clojure that the lack of language pain points lessened the need/motivation for experts to build their own RAD framework.
        Scarbutt 7y ago
        I'm not denying that something better than Rails can be built with Clojure, just implying that it doesn't exist, so for quickly pushing out a CRUD webapp multiple times without repeating yourself again and again(avoiding all the trivial/tedious stuff), there is Rails.
        blunte 7y ago
        Yup, and that's why Rails is what I still use :). Phoenix was pretty great too, but its real benefit came from doing bigger back-end stuff on BEAM.
  - mping 7y ago
    I generally agree with your statement, otoh I have used some libs that are not being actively maintained for years and they still work, out of the box. Clojure strength is its weakness. But yes, there is a long way to make it more beginner friendly
- mhd 7y ago
  This seems common in the Go culture, but I don't see at all why the language points in that direction (apart from Go having plenty of that in a barebones form in the std lib, of course). What language can't compose libs? The main problem is whether developers can. To me this often is "mental dark mode". You think you're more efficient, but usually aren't.
- thom 7y ago
  It sort of guarantees that in a couple of years time half your stack will then be unmaintained, though (at least in my 10 years of Clojure experience).
  - Zelphyr 7y ago
    That’s not limited to Clojure nor does it matter whether it’s a batteries included framework or not. I’m seeing this more and more, to the degree that often I’m back to rolling my own instead of relying on a library or framework that has a high likelihood to f being abandoned.
    - freehunter 7y ago
      More and more I'm of the opinion that I don't want to use a library that's not included in the core product. I've had way too many dependencies become end-of-life before my application was EOL, and I ended up having to fundamentally change my application, putting in hours of work just to keep things the same, or rebuild a feature. I appreciate Rails for all the built-in stuff it provides but anything outside of that, as time goes on you're getting more and more likely to end support. Paperclip hit me hard, and my Rails apps are stuck on an unsupported library because it's not worth the time or effort to migrate to ActiveStorage. God help me if Devise is deprecated. That's the reason I've tried to stay away from the current Javascript madness. All of modern Javascript is built on hundreds of NPM packages that will disappear in two or three years. I certainly will never use any language or framework in production if the main feature is "nothing is included, bring your own core features" like Flask or Express unless I'm committed to building those not-included core features myself (which I probably won't). Because if I'm bringing in someone else's package, even something that's well supported by a great and developer-friendly company like Thoughtbot, that package will likely EOL before my app does. Yes I'm still absolutely bitter about Paperclip being deprecated.
      - Zelphyr 7y ago
        All of modern Javascript is built on hundreds of NPM packages that will disappear in two or three years This is soooo true! I actually really like Javascript but NPM is in such a bad place and it's having effects outside of just it's ecosystem. We just built an app using Nativescript which by itself is actually pretty decent but we chose to use a plugin for a specific feature we needed. But then we kept running into problems with it and, after serious back-and-forth with the plugin maintainer, it turns out his plugin depends on another plugin that has had a known, very serious bug. And that project's maintainer has known about it for at least nine months but he has said he doesn't have time to fix it. I take that to mean he's lost interest and the project is effectively dead unless someone else comes along to take the reins in maintaining it. Which we assume means the original plugin that we chose to use is also effectively dead because it so heavily relies on the other plugin. In the end, we just removed all of the plugins as we determined they were hostile to our productivity and routed around them by rolling our own solutions.
- bcrosby95 7y ago
  Are either commonly used in the way Rails, Spring, and Django are? Clojure is niche but Go is big and I don't see many webapps powered by Go like they are in Ruby/Java/Python with Rails/Spring/Django. In the web world most Go programs I see are API backends. Here's why I think "just use composable libraries" is a bad idea: First it isn't very friendly to new developers. You tell them to go out there and find their libraries and they have zero clue where to start. The second problem is its not very friendly to developers with a couple years experience either. Frameworks take care of so much stuff that most people don't know they need to take care of. Not just obvious things like connecting to an RDBMS but also very basic stuff that every website will need like CSRF protection, session management, etc. And finally, when you rely on a wide variety of micro libraries you're actually relying a wide variety of other developers. What is going to have more support and development in the future: 10 libraries split across 10 developers with varying levels of commitment, or 1 framework with a group of developers working together on it? You don't need to build your framework like Rails or Django. You could make it easier to plug in other libraries. But it should have a sane default for everything it needs for the benefit of both new and intermediate developers. Spring kinda works like this. It's easy to use Spring libraries for different parts but you can also just use your own.
  - slifin 7y ago
    This is in constant discussion in the Clojure community but some of the draw backs of frameworks are that you start seeing libraries and code that only work with the big framework Even when they could have worked without it, and they over Shadow competitors in the space, why use that shiny new router library when my framework already has an one that's "easy" to reach And then of course the worst thing to happen to a code base, the framework it's built on falls out of favour and you can't hire devs or get security patches for it anymore "don't put your eggs in one basket", and "developers know the benefit of everything and the cost of nothing" applies here I think if a framework is to be successful in Clojure it needs to not be intertwined with itself in the "simple made easy" sense Additionally if the "interface" is data like you might get lucky enough that you get multiple implementations, like many cljs libraries support the react interface With declarative programming we could certainly keep the intention of code the same whilst changing out the implementation but it would require careful coordination between library creators and a open data interface so that new requirements can be satisfied later down the line and even then multiple variants to serve completely different approaches
- regulation_d 7y ago
  One reason I like Elixir's Phoenix is that it's reasonably easy to leave out the heavy-weight batteries I might not want, specifically the DB library and and JS build pipeline. I also like that router is pretty simple, but can handle complex REST-y things when you need it to. It doesn't feel, to me, either bloated or bare-bones, which is nice. all that to say, if there is in the Clojure ecosystem analogous, I'd like to hear about it.
lkschubert8 7y ago
I wonder if we wouldn't be better off with fewer frameworks and more well documented prescriptive lists of libs and how to use them together.

dvcrn 7y ago

IMO languages like Clojure (or Go) don’t need a fully powered batteries included web framework like Rails or Django. The approach to pick together what you actually need (router, db bits and pieces, etc) with composable libraries works really great

goostavos 7y ago
After having gone through this, I now disagree. There are a vast many things in which I am not an expert. The pick and choose / compose your libraries / lego approach sounds great until your trying to weigh different options (of which none seem to have a wide enough install base to be truly battle tested). Is buddy/buddy-auth the way to go for security? Or is it Friend? The former seems to receive more recommendations as of late, whereas the latter has more activity on github. These are not the problems I want to be solving when building something. I love the language, but the quality of Clojure's web ecosystem is... questionable. If I were to build another webapp in Clojure, I think I'd just use something widely installed like Jersey for actually interfacing with the outside world. It'll be crufty Java, but it has nice things like StackOverflow activity, massive docs, giant userbase, etc.. etc..
- blunte 7y ago
  You express exactly what has kept me from doing webdev with Clojure, despite my (now perhaps irrational) love for the language. I will learn whichever language allows me to get my site/app done as quickly as possible at first. Later after I have refined and refactored enough to know what's up... then I may decide to change. Nextjs (despite the javascript), Rails (Ruby is great!... not Clojure, but pretty good), Django (Python is low-pain, low-effort), etc. are all easy quick ways to actually get something done BEFORE you really know what you're doing. This is critically important for those of us who don't spend all our time doing public-facing web apps.
  - Scarbutt 7y ago
    As someone who tries to use Clojure everywhere I can, its very hard to beat Rails for pushing out a webapp (many long Clojure timers share this opinion). Clojure shines for web services that require lots of data processing in the server and for integrating with parts of the Java ecosystem.
    - blunte 7y ago
      I have not investigated Coast yet. I know it aims to be a Rails for Clojure... maybe it is, and maybe it would meet my needs. But given the incredible power and expressiveness of Clojure, I find no reason to believe that the best rapid web development framework could be developed in Clojure if the right motivated people attempted to do so. I don't know how many people (Plataformatec?) were behind Phoenix, but even in its early versions it was comparable to Rails. In some ways, it was even better. There seem to be two obstacles to doing this in Clojure. The first is that people who actually know enough about Clojure to do this are actually very busy (happily) doing Clojure for work. They don't have the personal need to build a Rails for Clojure. The second is that those who would be capable already know how to pick and choose the libraries and build their own (even better, more suited for the purpose) ad-hoc frameworks for their projects. I suppose it could be a curse of the power of Clojure that the lack of language pain points lessened the need/motivation for experts to build their own RAD framework.
      - Scarbutt 7y ago
        I'm not denying that something better than Rails can be built with Clojure, just implying that it doesn't exist, so for quickly pushing out a CRUD webapp multiple times without repeating yourself again and again(avoiding all the trivial/tedious stuff), there is Rails.
        blunte 7y ago
        Yup, and that's why Rails is what I still use :). Phoenix was pretty great too, but its real benefit came from doing bigger back-end stuff on BEAM.
- mping 7y ago
  I generally agree with your statement, otoh I have used some libs that are not being actively maintained for years and they still work, out of the box. Clojure strength is its weakness. But yes, there is a long way to make it more beginner friendly
mhd 7y ago
This seems common in the Go culture, but I don't see at all why the language points in that direction (apart from Go having plenty of that in a barebones form in the std lib, of course). What language can't compose libs? The main problem is whether developers can. To me this often is "mental dark mode". You think you're more efficient, but usually aren't.
thom 7y ago
It sort of guarantees that in a couple of years time half your stack will then be unmaintained, though (at least in my 10 years of Clojure experience).
- Zelphyr 7y ago
  That’s not limited to Clojure nor does it matter whether it’s a batteries included framework or not. I’m seeing this more and more, to the degree that often I’m back to rolling my own instead of relying on a library or framework that has a high likelihood to f being abandoned.
  - freehunter 7y ago
    More and more I'm of the opinion that I don't want to use a library that's not included in the core product. I've had way too many dependencies become end-of-life before my application was EOL, and I ended up having to fundamentally change my application, putting in hours of work just to keep things the same, or rebuild a feature. I appreciate Rails for all the built-in stuff it provides but anything outside of that, as time goes on you're getting more and more likely to end support. Paperclip hit me hard, and my Rails apps are stuck on an unsupported library because it's not worth the time or effort to migrate to ActiveStorage. God help me if Devise is deprecated. That's the reason I've tried to stay away from the current Javascript madness. All of modern Javascript is built on hundreds of NPM packages that will disappear in two or three years. I certainly will never use any language or framework in production if the main feature is "nothing is included, bring your own core features" like Flask or Express unless I'm committed to building those not-included core features myself (which I probably won't). Because if I'm bringing in someone else's package, even something that's well supported by a great and developer-friendly company like Thoughtbot, that package will likely EOL before my app does. Yes I'm still absolutely bitter about Paperclip being deprecated.
    - Zelphyr 7y ago
      All of modern Javascript is built on hundreds of NPM packages that will disappear in two or three years This is soooo true! I actually really like Javascript but NPM is in such a bad place and it's having effects outside of just it's ecosystem. We just built an app using Nativescript which by itself is actually pretty decent but we chose to use a plugin for a specific feature we needed. But then we kept running into problems with it and, after serious back-and-forth with the plugin maintainer, it turns out his plugin depends on another plugin that has had a known, very serious bug. And that project's maintainer has known about it for at least nine months but he has said he doesn't have time to fix it. I take that to mean he's lost interest and the project is effectively dead unless someone else comes along to take the reins in maintaining it. Which we assume means the original plugin that we chose to use is also effectively dead because it so heavily relies on the other plugin. In the end, we just removed all of the plugins as we determined they were hostile to our productivity and routed around them by rolling our own solutions.
bcrosby95 7y ago
Are either commonly used in the way Rails, Spring, and Django are? Clojure is niche but Go is big and I don't see many webapps powered by Go like they are in Ruby/Java/Python with Rails/Spring/Django. In the web world most Go programs I see are API backends. Here's why I think "just use composable libraries" is a bad idea: First it isn't very friendly to new developers. You tell them to go out there and find their libraries and they have zero clue where to start. The second problem is its not very friendly to developers with a couple years experience either. Frameworks take care of so much stuff that most people don't know they need to take care of. Not just obvious things like connecting to an RDBMS but also very basic stuff that every website will need like CSRF protection, session management, etc. And finally, when you rely on a wide variety of micro libraries you're actually relying a wide variety of other developers. What is going to have more support and development in the future: 10 libraries split across 10 developers with varying levels of commitment, or 1 framework with a group of developers working together on it? You don't need to build your framework like Rails or Django. You could make it easier to plug in other libraries. But it should have a sane default for everything it needs for the benefit of both new and intermediate developers. Spring kinda works like this. It's easy to use Spring libraries for different parts but you can also just use your own.
- slifin 7y ago
  This is in constant discussion in the Clojure community but some of the draw backs of frameworks are that you start seeing libraries and code that only work with the big framework Even when they could have worked without it, and they over Shadow competitors in the space, why use that shiny new router library when my framework already has an one that's "easy" to reach And then of course the worst thing to happen to a code base, the framework it's built on falls out of favour and you can't hire devs or get security patches for it anymore "don't put your eggs in one basket", and "developers know the benefit of everything and the cost of nothing" applies here I think if a framework is to be successful in Clojure it needs to not be intertwined with itself in the "simple made easy" sense Additionally if the "interface" is data like you might get lucky enough that you get multiple implementations, like many cljs libraries support the react interface With declarative programming we could certainly keep the intention of code the same whilst changing out the implementation but it would require careful coordination between library creators and a open data interface so that new requirements can be satisfied later down the line and even then multiple variants to serve completely different approaches
regulation_d 7y ago
One reason I like Elixir's Phoenix is that it's reasonably easy to leave out the heavy-weight batteries I might not want, specifically the DB library and and JS build pipeline. I also like that router is pretty simple, but can handle complex REST-y things when you need it to. It doesn't feel, to me, either bloated or bare-bones, which is nice. all that to say, if there is in the Clojure ecosystem analogous, I'd like to hear about it.

lkschubert8 7y ago

I wonder if we wouldn't be better off with fewer frameworks and more well documented prescriptive lists of libs and how to use them together.