This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-01-29
Channels
- # announcements (17)
- # aws (12)
- # babashka (27)
- # beginners (85)
- # bristol-clojurians (1)
- # calva (16)
- # cider (3)
- # clara (7)
- # clojure (80)
- # clojure-europe (13)
- # clojure-italy (19)
- # clojure-nl (2)
- # clojure-norway (6)
- # clojure-poland (1)
- # clojure-spec (31)
- # clojure-uk (61)
- # clojurescript (29)
- # core-async (10)
- # cursive (7)
- # data-science (1)
- # datomic (29)
- # docker (3)
- # fulcro (120)
- # graphql (16)
- # hugsql (2)
- # leiningen (17)
- # luminus (2)
- # off-topic (36)
- # other-languages (3)
- # pathom (13)
- # re-frame (12)
- # ring (2)
- # rum (1)
- # shadow-cljs (126)
- # tools-deps (56)
- # vscode (5)
Fulcro seems like a front-end story that is similarly heavily opinionated, but still not complected together. That, and the fact that JS interop is far better in CLJS makes it a better choice than ELM IMHO. Of course there's Google Closure and the stability and the simplicity of the language itself.
Just started the Omnigraffle trial. Where can I learn how to use Omnigraffle? Is their manual the best place?
After watching Rich's transducer, PREPL and tools deps diagrams, I feel like I have to give this thing a shot.
At least to me, it doesn't feel like the value proposition of clojurescript is that good nowadays
While there is an argument to be made that having persistent structures as the default and the lisp repl workflow being useful
At least on the browser most changes to code I make are along a "redux-y" path, where I am changing how an event is dispatched or handled, or to the styling or structure of a page
And even without persistent structures, regular JS works decently well for functional programming
Which is all to say I don't think the benefits of clojure outweighs the downsides of using the clojure ecosystem in the browser
But being married to Google closure is still something that the existence of "advanced compilation" doesn't justify
I love Elm - but I certainly am looking forward to trying clojurescript - the one thing with elm - is that it's whole framework not just a language - it's just more specialized - which helps if you are doing something it is meant to do - but restricts you otherwise
And interacting with JS libraries feels nicer with async await in javascript than wrapping that behavior in core.async and eating bad stack traces
I used to believe that Elm's restrictions were it's main downside and that clojurescript's permissiveness was it's main upside
(also put a thousand large asterisks next to everything I say because I really don't know what im talking about at the end of the day)
my take is that, 90% of the work being done in front-end dev is not very novel. and a lot of traditional software businesses aren’t structured/incentivized in a way to invest in the 10% that is. so there’s a race to the bottom to try and create the best lever to save labor and standardize on it
CLJS and Elm take different approaches to that. CLJS gives you much better interop than some other compile-to-js langs, to use the latest shiny lever how you see fit. But you still run into problems there where the interop layer leaks all over your code at times if you’re not careful in your abstraction.
Elm takes the path of “we can build a better lever” with types and its opinionated architecture
at the end of the day, JS is what most people are writing all these levers with and if you want optimal builds, not worrying about interop, etc. JS is the best compile-to-JS lang for that 😅
It's kind of interesting that you see the same problems come up in different compile-to-JS ecosystems, particularly, making the 'wrong' bet on some tooling choice or other. For example: CLJS uses the closure compiler, but the wider ecosystem has standardised on alternatives to that for basically everything it does (eg, typescript for types, and if you want tree shaking, you use a bunch of tentacles in your webpack config and es6 modules). But I notice that the Purescript people are (or were) stuck using Bower, of all things, for package management because of semantic differences with NPM's packaging. And even Ember is now bogged down with a load of tech debt replacing the innards of its toolchain with stuff that's used more widely. In all cases the choice was made for very good reasons; closure got lean builds when nothing else would; Bower really is a better fit for Purescript; and the Ember community pioneered the idea that the compiler should be part of the framework in JS-land, at a time when the currently-popular tools were ... not good. That's why I put wrong in scare quotes. But in the end, running with the herd is an enormous advantage over almost everything else. (Having Facebook paying dozens of salaries doesn't hurt either ... ) And once these fundamental technical choices are made, they're incredibly difficult to change without breaking lots of things. I've kind of lost touch with Elm, maybe it worked out perfectly for them 😅
apparently the protagonist in The Unicorn Project (the next book from the author of The Phoenix Project) is a Clojure enthusiast? Its her favorite language
That's because the author is a Clojure enthusiast (and gave a keynote at Conj).
Here's the article he wrote: https://itrevolution.com/love-letter-to-clojure-part-1/