[HN Gopher] Coast on Clojure
___________________________________________________________________
Coast on Clojure
Author : adamkl
Score : 105 points
Date : 2022-04-05 11:47 UTC (11 hours ago)
(HTM) web link (coast.swlkr.com)
(TXT) w3m dump (coast.swlkr.com)
| maxfurman wrote:
| This looks very nice! Happy to see something batteries-included
| for the Clojure crowd. How does this compare to Luminus?
| swlkr wrote:
| Always nice when one of my projects makes it to the front page!
|
| I haven't worked on this one much lately, but I'm happy to answer
| any questions!
| janetacarr wrote:
| This is cool, but, aside from error messages, it resembles
| Clojure's biggest problem right now: Everyone keeps trying to re-
| invent the wheel with respect to creating the "Rails" for
| Clojure.
|
| We have several production grade libraries and frameworks for
| serving webpages. Reitit(router), yada(http standards),
| bidi(router), aleph (netty wrapper), ring (jetty wrapper),
| pedestal (bundle of libraries), luminus (self described micro-
| framework), the list goes on, yet Clojure's biggest pain point is
| the lack of other production grade libraries for other/mundane
| things.
|
| If the libraries do exist, they can barely cut a stable release
| (like 2.0.0-alpha24) or keep up with changes to prevent software
| rot.
| mtnygard wrote:
| Looks like this is mostly Ring + Hiccup
| (<https://github.com/coast-
| framework/coast/blob/master/deps.ed...>) with a DB connection
| pool.
| gleenn wrote:
| I always struggle with the idea that "frameworks are bad, combine
| libraries instead," it makes sense and makes orthogonal libraries
| not step on each other or make things more complicated. The thing
| lost is having an easy time getting up and running quickly. I was
| always a big Liminus champion fir this reason, they tried really
| hard to group a good set of libraries and document it all well.
| Bur this work is also fantastic. Sometimes, you really just want
| to get something done, and the batteries included solution might
| be the thing that gets your project done. I came from Ruby on
| Rails and will always miss that ability to get a DB connected,
| Javascript enabled, dynamic website onto something like Heroku
| from 0 to production in like... 20 minutes. So thanks for Coast,
| looks like it will help fill in an important part of the tooling
| spectrum.
| andrewzah wrote:
| Agreed, that's why I find it so difficult to leave rails/ruby.
| I really like Clojure+Datomic+Clojurescript but I can't justify
| the extra work needed compared to the extensive tooling and
| library support that rails has since it's mature and widely
| used.
| EsotericAlgo wrote:
| The good 'ole days.
|
| You're paying the tax at some point, but if that's at the start
| of the project it might be high enough to stop it in its
| tracks. A mature Rails or Django project require abstracting
| configuration later on in development which is a different sort
| of tax.
|
| Convention over configuration absolutely has it's perils. I've
| unfortunately (fortunately?) hit this enough times with
| Clojure, I know the ecosystem well-enough I'd personally pick
| composition for a personal project. In a team project where
| composition makes collaboration difficult (generally a
| communication and experience problem) I'd probably choose
| another language with an opinionated framework.
| adamkl wrote:
| Agree. There is a lot of value in the "easy, batteries
| included" solution which is why Rails gets so much love from
| the start-up community. The problem always seems to be that the
| same things that makes Rails easy to get started with ( _cough_
| ActiveRecord _cough_ ) also make it easy to create foot-guns in
| the future (provided your start-up lasts long enough to get to
| that point).
|
| Combining a Rails like framework that makes things easy with a
| language who's idioms prioritize simplicity seems like a great
| combination.
| slowmovintarget wrote:
| To quote Rich Hickey: "gem install hairball"
| adamkl wrote:
| I like that quote, but it's the Rails idioms and
| conventions that make hairballs, not the fact that it
| includes a bunch of batteries.
| capableweb wrote:
| Adopting any framework is quite literally adopting the
| framework's idioms and conventions so not sure how that
| is different.
| ravi-delia wrote:
| > Combining a Rails like framework that makes things easy
| with a language who's idioms prioritize simplicity seems like
| a great combination.
|
| I think that's what makes Phoenix and Elixir so nice to use.
| The primitives Phoenix uses aren't too far from the surface,
| and the default setup is fairly batteries included without
| ruling out future growth.
| dimitrios1 wrote:
| I am going to butcher this, but my sense is this counter
| culture against the big heavy opinionated frameworks arose
| from that generation of programmers who in a sense "grew up"
| (career wise) on things like Rails. Like others have said,
| there eventually comes a time where you are fighting the
| framework more than the framework is providing value, and
| having learned the value of the abstractions and
| functionality through multiple applications, they then became
| able to pick and choose a finer subset for a particular
| problem or domain.
|
| The best of both worlds, in my opinion, is a loosely coupled
| set of opinionated tools and libraries, but that also has a
| tool that provides a unifying interface into the "golden
| path" for using those together to provide some functionality.
| dgb23 wrote:
| > The best of both worlds, in my opinion, is a loosely
| coupled set of opinionated tools and libraries, but that
| also has a tool that provides a unifying interface into the
| "golden path" for using those together to provide some
| functionality.
|
| This is almost it. A few more things I think one wants:
|
| - Do most of the coupling and plumbing yourself, IoC is
| evil when applied to things that do too much.
|
| - Control the application state - see above.
|
| - Be free to substitute any major part, be able to compose
| them freely.
|
| - Re-use and extracting libraries from past work to be
| convenient, robust and affect past / maintenance-mode
| projects positively too.
|
| - Be able to defer extracting libraries and generalizing up
| to the time you actually need to.
|
| - Decouple code organization from artifact deployment.
|
| - Be absolutely free in how you design and write domain
| logic and information processing - this is the brain of an
| application.
|
| - Be absolutely free in how you design and write the UI -
| this is the body of an application.
|
| - Have the tooling/utilities around code that fit your
| workflows and business needs.
|
| I've come to the conclusion that full-stack frameworks in
| the style of Rails/Laravel/Django get in the way of some of
| the above and don't provide enough to make the above
| possible by themselves. I think the answer is not "use this
| framework" or even "build this framework".
|
| It starts with your business/domain needs and builds from
| there - custom and simple. It builds up slowly and steadily
| like a garden that reflects your team's personality. It
| takes a careful, comprehensive, holistic approach. There
| are angles from version control, to project management to
| deployment that are all incorporated.
| adamkl wrote:
| Sounds like "create-react-app". A bunch of libraries and
| configurations wrapped up in a "golden-path".
|
| Provides the "easy" for 95% of usecases and an "eject"
| button that unwraps everything and puts it under you
| control for the last 5%.
| dimitrios1 wrote:
| Create react app was one example I had in mind, I think
| Redwoodjs is another one that recently popped up.
| 0xferruccio wrote:
| Love to see Coast getting some attention again! I got my start
| into Clojure with it working with Sean on small web apps written
| in Coast. I even gave a talk about it at the Berlin Clojure
| conference
|
| https://youtu.be/24PRtDJGvW8
|
| The first project we built together with it was called magehash,
| and it was an app to monitor websites for Magecart attacks (code
| injection stealing credit card data).
|
| That project ended up not working out, but I'm using a lot of the
| lessons I learned with Sean at my new project
| (https://www.june.so) which is ironically a Rails app and we keep
| in touch on Twitter regularly
| swlkr wrote:
| So much fun working on that project!
|
| Turns out it's really hard to beat the productivity of rails
| mark_l_watson wrote:
| Thanks for posting this. I might want to give it a try with my
| very old 'smart' nutrition and cooking website [1] that I wrote
| in Clojure about 10 years ago and have not touched it in years. I
| wanted to update it a few years ago but the Clojure web
| libraries/frameworks I used are no longer supported.
|
| [1] http://cookingspace.com
| the-alchemist wrote:
| Looks great! I also like the informal, conversational tone of the
| documentation. :)
| phyrex wrote:
| I loved Coast and wrote at least one production app with it (and
| very quickly and pleasantly at that), but it needs to be said
| that swlkr is the only developer, and he seems to have mostly
| moved on to Janet (https://janet-lang.org/). Case in point, the
| last real updates to Coast were 2 years ago, and - unlike other
| Clojure libraries - not because this project was /finished/.
| swlkr wrote:
| Yeah, I did move on, but if someone were to pick up the torch,
| I would help out any way I can!
| jtth wrote:
| biff (https://biffweb.com/) is a little more batteries-included
| but seems like a nice successor in this space
| threatofrain wrote:
| I'm surprised to hear that Janet is still alive and kicking!
| cube2222 wrote:
| Slightly OT, but whenever I see Clojure projects I think: "I'd
| love to write something bigger in Clojure one day, experience it,
| and see if it's all it was promised to be."
|
| That said, I don't really have any good use case for it right
| now, whether at work, or among my side projects.
| Jonovono wrote:
| Same here! I wanted to learn it and Overtone years ago, tried
| to, realised my brain was just not prepared ;p.
|
| I have a bit of time now and I am diving in again and am more
| determined this time!
|
| I got clojurescript going with react native, and having fun so
| far. If you need inspiration check out Rich Hickleys talks. He
| keeps me going through the hard times!
| ARandomerDude wrote:
| React and ReactNative in Clojure(Script) are amazing if you
| work in that area. Honestly, I'd never go back to a JS
| implementation. Reagent [1] provides a seamless interface for
| components, classes, hooks, etc. and ShadowCljs [2] is a
| fantastic build tool for the ecosystem. Re-frame [3] is a
| popular framework in this space.
|
| [1] https://reagent-project.github.io/
|
| [2] https://github.com/thheller/shadow-cljs
|
| [3] https://github.com/day8/re-frame
| Jonovono wrote:
| This is exactly what I just set up! Super cool - coming from
| doing Redux sagas and hooks and redux and all that stuff on
| RN it's been really interesting. Would you recommend Shadow
| vs Krell? I have tried both and so far Shadow was the most
| seamless, but Krell seems the most lightweight.
|
| If you care to share, i'd love to learn what you are building
| with it.
| ARandomerDude wrote:
| I haven't used Krell, but Shadow has been great for me.
| Been on it a couple years now.
|
| My company is in the smarthome/IOT space and we use
| React(Native) + Clojure and ClojureScript for all our apps,
| dashboards, servers, etc.
| curuinor wrote:
| I'm a year and change into my job at metabase (metabase.com)
| writing clojure all day every day and I am still terribly
| surprised that basically it is all that it's promised to be.
|
| That said, you do need to actually use the repl and be repling
| all the time because the startup times suck and the stack
| traces are gigantic all the time. That's pretty much it for
| complaints. You would expect things that aren't apparent in 30
| minutes looking at the language to come up after an entire
| year, but nothing so far.
| giraffe_lady wrote:
| Oh wow yeah I forgot about the stack traces. Clojure was the
| second programming language I ever learned, after self-
| teaching ruby. lmao ruby does not prepare you for a 700-line
| stack trace full of java classes you've never even heard of
| because they're deep in the implementation.
|
| Does it still do that? I remember "better error messages"
| being a supposedly-coming-soon thing for the couple years I
| was using it. I eventually got used to it but damn what a
| hostile experience. In retrospect I'm pretty surprised I
| stuck with it. For better or worse I don't have that same
| tolerance & resilience now.
| ashes-of-sol wrote:
| Error messages are much easier to parse now!
| capableweb wrote:
| (Seems your comment was dead, but I vouched for it as
| it's contributing to the discussion)
|
| Yeah, with the arrival of clojure.spec, some error
| messages has indeed gotten easier to both read and parse
| (for humans and machines alike), although when you use
| Clojure JVM so still come across the odd huge Java stack-
| trace (or with ClojureScript, a pretty sizable JavaScript
| stack-trace).
| ravi-delia wrote:
| I definitely recommend messing around with it, even just for a
| toy, but yeah I'm in a pretty similar boat. Can't think of any
| specific use case that I don't prefer another language for. On
| the lookout though!
| jcadam wrote:
| I did clojure as a hobbyist for years and have only recently
| taken a job where I'm working full time in Clojure on a large
| codebase (i.e., first time having to maintain somebody else's
| Clojure code). It's not a golden hammer by any means, but I'd
| definitely take it over Java (or Scala) any day.
| phtrivier wrote:
| Unless I missed something in the doc, it seems like it's the
| "Fullest full stack framework" as long as you're only interested
| in the "handling web server request and reply with html" part of
| the full stack.
|
| Any reason why this should be used instead of cooking up ring /
| hickup / whatever ?
___________________________________________________________________
(page generated 2022-04-05 23:01 UTC)