Fork me on GitHub
#off-topic
<
2020-01-29
>
jaihindhreddy15:01:52

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.

jaihindhreddy16:01:22

Just started the Omnigraffle trial. Where can I learn how to use Omnigraffle? Is their manual the best place?

jaihindhreddy16:01:58

After watching Rich's transducer, PREPL and tools deps diagrams, I feel like I have to give this thing a shot.

emccue16:01:58

As blasphemous as it is to say, I don't particularly like clojurescript

emccue16:01:14

I far prefer elm for most cases

emccue16:01:29

Which I should probably justify (though justify is a strong word)

emccue16:01:56

At least to me, it doesn't feel like the value proposition of clojurescript is that good nowadays

emccue16:01:32

While there is an argument to be made that having persistent structures as the default and the lisp repl workflow being useful

emccue16:01:34

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

emccue16:01:54

For those usecases full hotreload is good enough

emccue16:01:04

And even without persistent structures, regular JS works decently well for functional programming

emccue16:01:51

Which is all to say I don't think the benefits of clojure outweighs the downsides of using the clojure ecosystem in the browser

emccue16:01:37

When I last was learning clojurescript npm support was annoying at best

emccue16:01:49

Which I understand that shadowcljs has fixed

emccue16:01:22

But being married to Google closure is still something that the existence of "advanced compilation" doesn't justify

jakubl16:01:51

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

emccue16:01:20

And interacting with JS libraries feels nicer with async await in javascript than wrapping that behavior in core.async and eating bad stack traces

emccue16:01:02

I used to believe that Elm's restrictions were it's main downside and that clojurescript's permissiveness was it's main upside

emccue16:01:46

But I now hold the belief that making web apps is actually a very narrow task

emccue16:01:26

And doing it in the super restricted way is a good way to reduce complexity over time

emccue16:01:55

Or rather, elm is simple; clojurescript is easy

❤️ 4
emccue16:01:54

(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)

lilactown16:01:25

I somewhat agree with you emccue

lilactown16:01:35

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

lilactown16:01:54

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.

lilactown16:01:53

Elm takes the path of “we can build a better lever” with types and its opinionated architecture

lilactown17:01:32

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 😅

tragiclifestories17:01:20

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 😅

dpsutton19:01:50

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

dpsutton19:01:26

haven't read it but loved the phoenix project

seancorfield19:01:35

That's because the author is a Clojure enthusiast (and gave a keynote at Conj).

dpsutton19:01:43

oh . which conj?

dpsutton19:01:01

awesome. thanks