edge
component
edge | component | |
---|---|---|
1 | 13 | |
502 | 2,068 | |
0.0% | 0.0% | |
2.6 | 0.0 | |
over 2 years ago | about 2 years ago | |
Clojure | Clojure | |
MIT License | MIT License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
edge
-
Clojure needs a Rails, but not for the reason you think
I totally respect that, and Clojure could invest more in offering frameworks or even no-code platforms or such features, but the truth is it doesn't. The language very much targets the software/information engineer category in my opinion, where by that I mean, the people who are interested in not just the functional requirements, but also the non-functional requirements of performance, scale, architectural runway, future extensibility, operations, maintainability, correctness, re-usability, etc. Especially, Clojure targets those who believe a balance between all these and functional requirements is the holy grail. That's why it won't be the most correct, the most performant, the most productive, but a pragmatic balance of all these in almost equal parts.
Maybe it should also embrace the people looking to get a product out by simply using a framework, and I'd say there's more of that in Clojure today than ever before, but the community I think is more composed of the former people that I describe, which is why you don't see any attempted framework take hold in the community, because most current members are not in the group that "just want to build the product using an established framework".
I think the community has settled, ounce again, on a bit of a balanced approach, Kit (https://github.com/kit-clj/kit) and Edge (https://github.com/juxt/edge) are such hybrids. And some more direct viable frameworks have come along like Biff (https://biffweb.com/) and Fulcro (https://fulcro.fulcrologic.com/).
That said, since the community is more composed of people like me, you don't see a mass move of every Clojurian switching to one of those.
So it creates some questions?
1. Is it a problem that the language targets engineers more interested in a balance between non-functional and functional?
2. Should it be mutually exclusive, or can Clojure equally serve both niche? And if so, should it, why?
3. Is the claim that you can be as productive and it is just as easy to build a product without using a framework in Clojure true? Does this apply to everyone, or only certain personalities or people with certain amount of lower level knowledge?
4. Is Clojure's marketing misleading? Are people looking to just "build the product using an established framework" mislead in thinking Clojure will offer them salvation?
5. Where do most developer fall in, if they don't fall in the category Clojure currently targets, than does that mean Clojure cannot become mainstream? To go mainstream does it mean you have to target frameworks because there are more developers looking to just make a product using a framework?
I don't have answers to these, I'm just trying to define the current state and what the problem with it might be, or if it even is a problem.
component
-
A History of Clojure (2020) [pdf]
* Lifecycle management: Mount, Integrant or Component (https://github.com/tolitius/mount https://github.com/weavejester/integrant and https://github.com/stuartsierra/component)
-
Generic functions, a newbie question
When you start to have multiple stateful components (the database, the HTTP server, your Redis connection, a page cache, etc.), then you'll want to use a library like component that manages their (inter-)dependencies and provides a consistent notion of lifecycle.
- What makes Clojure better than X for you?
- Clojure needs a Rails, but not for the reason you think
-
[ANN] Reveal Pro 1.3.308 — sticker windows for system libraries (component, integrant, mount)
Today I released a new version of Reveal Pro — dev.vlaaad/reveal-pro {:mvn/version "1.3.308"} — that adds sticker integration for system libraries such as mount, component and integrant!
-
Printf(“%s %s”, dependency, injection)
I agree with the main sentiment from the article. Although I do think they are discussing Inversion of control more-so than dependency injection.
One of my first languages was .net and I was never able to really understand DI in that context that well.
Actually using javascript and ducktyping made me understand what it actually was.
I remember a .net job interview where I had to write a micro-service and opted to construct the dependency graph in the main function initialising "all" the classes there. Instead of discussing the pro's and con's of that approach they berated me for not using a DI framework (No I did not land that job, but in hindsight it was the most expensive job interview I've ever had. The room was filled with 8 developers going over my code).
The main thing the article glosses over is state. something people with a functional background hide from. But if you look at something like the httpclient in .net. I think it took the .net world like 10 years to start using the httpclient properly. Scope and lifetime of those kind of objects are important. managing connection pools, retry state, throttling or the incoming http request. DI does make that kind of thing easieR (I'm not saying it makes it better)
Look at clojure's component(https://github.com/stuartsierra/component), I'm not a clojure expert by far. But it is kinda DI/IOC in a functional language.
In closing we can agree that it is underused in the right places and overused in the wrong ones.
- Forcing engineers to release by some arbitrary date results in shipping unfinished code - instead, ship when the code is ready and actually valuable
-
How to pass components across functions
https://github.com/stuartsierra/component#no-function-should-take-the-entire-system-as-an-argument
-
There are a *lot* of actor framework projects on Cargo.
Yeah like I mentioned I'm not like super sold on the everything-should-be-an-actor paradigm, but I find value in DDD + a light implementation of Components (similar to stuartsierra/component).
-
Essential libraries?
https://github.com/stuartsierra/component for managing components lifecycles in projects
What are some alternatives?
yada - A powerful Clojure web library, full HTTP, full async - see https://juxt.pro/yada/index.html
integrant - Micro-framework for data-driven architecture
luminus-template - a template project for the Luminus framework
reitit - A fast data-driven routing library for Clojure/Script
paos - Clojure SOAP client
mount - managing Clojure and ClojureScript app state since (reset)
bidi - Bidirectional URI routing
ultra - A Leiningen plugin for a superior development environment
ripley - Server rendered UIs over WebSockets
awesome-clojure - A curated list of awesome Clojure libraries and resources. Inspired by awesome-... stuff
lein-figwheel - Figwheel builds your ClojureScript code and hot loads it into the browser as you are coding!
Luxon - ⏱ A library for working with dates and times in JS