4 ms·

Last week some nice folks assured me tooling was good in Clojure; and not a total time suck, and so I'm getting ready to take the jump I think... but, one thing

Last week some nice folks assured me tooling was good in Clojure; and not a total time suck, and so I'm getting ready to take the jump I think... but, one thing I'm still really skeptical about... is embodied in this paragraph: > The way the languages are integrated today, Clojure developers doing full-stack development don’t really have to think about data serialisation/deserialisation. Writing code for frontend and backend differ mostly just in the way that the different implementations access the host platform. The functional aspects of Clojure, especially the immutability and focus on referential transparency, ensure that source code is mostly split into chunks of highly portable code, with the host-interop conveniently put aside in its own sections. You can move code between frontend and backend at your leisure. Is it really that good using Clojure across environments and runtimes? I ask because I tried all of this with Scala years ago (I loved the language) and Ruby to an extent, but it was pretty miserable or rather there was really no reward but more effort on my part. I.e. I'd spend more time annotating, bridging, and learning how to interact with the different runtime than I would writing actual feature code[1]. Or like what are the killer libraries everyone loves? Do they (libs/frameworks) support different clojure runtimes ("hosts?") outta the box? Is it easy to write "pure clojure" projects that work for any clojure project? The one I know about or have heard most about was Datatomic, which always sounded freakin' brilliant, but I don't fucks with non-free databases. Arcadia I just saw and it looks cool but, it also seems like a dumb mountain to climb, if that's how I wanted to start screwing around with Clojure. [1] Tools like Scala/ScalaJS and RubyMotion (back in the day, heh), were the reasons I ended up a polyglot. They're great tools, if you know the platform, if you don't, you're pretty much still fucked... but once you know the platform it's kind of hard to want to use them.

throw03172019 7y ago
I have been writing helper libs with our shared logic in Clojure (CLJC). It is pretty nice to have the same core on the frontend and backend. It is easy enough to use the conditionals to call a Java fn vs. Javascript for certain logic (I.e Dates, etc)
scarredwaits 7y ago
I can attest that full stack (server-browser) Clojure code sharing works very-very smoothly. I've been developing web applications like that for some time now, and apart from less context swithing (because it's the same language on both sides), sizeable parts of the code are cross-compiled to run both on the browser and the JVM with very little or no extra effort. Example 1: I'm using Clojure's Spec library for validation. There is code that is used on the browser to validate the input that users enter into forms, and the same exact code is used on the HTTP endpoints that are called when the user attempts to submit the form. Example 2: I'm using the Tongue library to provide client-side translations of the whole UI, but the same data files and library are used in some cases on the server to generate files that contain translated strings. Example 3: The web UI logic is written using pure data manipulation (thank the Re-frame library for that) and because of that we are able to unit test it on the JVM without having to go through the complecity of launching and driving a browser on our CI server.
- rubyn00bie 7y ago
  Thank you so much for the response! Number 3 has me totally stoked; since that's incredibly valuable-- or like a dream to me to be honest, could you speak more about how that works? Is it just from using re-frame (which I'm looking at as I write this)? Is it able to test for visual regressions because of the pure-data UI? Or like how have you found that testing functionality in practice has it been saving y'all a lot of bugs and headaches you think?
  - rufugee 7y ago
    Agreed... would love to hear more about this as well....
    - simongray 7y ago
      Check out my reply to rubyn00bie.
  - simongray 7y ago
    The way Re-frame works, almost all of your application logic is represented with immutable tuples and maps (called "events" in Re-frame jargon). The parts that can't be represented this way, i.e. need to access the DOM, are moved to the edges of the codebase and are called "effects" and "coeffects". In practice, 80-90% of your application code can be represented as events, while the remainder becomes effects and coeffects. Your application logic is effectively a finite state machine and you can unit test all of it. The visual part of Re-frame is handled by reagent, which is a minimalist React wrapper that represents React components as pure functions, JSX as built-in Clojure data structures literals (hiccup), and state transformations using Clojure's idiomatic atom data structure. Re-frame builds on top of this base, by enforcing that a single atom (called db) holds all of the state and providing a DSL to create cursors into parts of it. Like most things in Clojure, Re-frame's initial setup is not a straitjacket and you can swap out the state atom with e.g. an in-memory datalog database using posh/re-posh and make the data retrieval completely declarative too.
slifin 7y ago
A lot of Clojure libraries will be described as Clojure(Script) libraries which means they run on both Java and JS usually with no interface changes here are some examples: https://github.com/tonsky/datascript https://github.com/tonsky/datascript https://github.com/Engelberg/instaparse https://github.com/Engelberg/instaparse https://github.com/wilkerlucio/pathom https://github.com/wilkerlucio/pathom Interop with hosts is a core feature of the language so it feels natural to reach for it when you need it and it's easy to write code that handles multiple runtimes but 95% of the time maybe more you don't need explicit runtime features
yogthos 7y ago
My team is developing full stack apps with Clojure, and using Clojure on the backend with ClojureScript on the frontend is completely seamless. I copresented a talk on the platform my team develops and how we leverage Clojure features there, specifically the ability to cross-compile between Clojure and ClojureScript that might be of interest https://www.youtube.com/watch?v=IekPZpfbdaI https://www.youtube.com/watch?v=IekPZpfbdaI

throw03172019 7y ago

I have been writing helper libs with our shared logic in Clojure (CLJC). It is pretty nice to have the same core on the frontend and backend. It is easy enough to use the conditionals to call a Java fn vs. Javascript for certain logic (I.e Dates, etc)

scarredwaits 7y ago

I can attest that full stack (server-browser) Clojure code sharing works very-very smoothly. I've been developing web applications like that for some time now, and apart from less context swithing (because it's the same language on both sides), sizeable parts of the code are cross-compiled to run both on the browser and the JVM with very little or no extra effort. Example 1: I'm using Clojure's Spec library for validation. There is code that is used on the browser to validate the input that users enter into forms, and the same exact code is used on the HTTP endpoints that are called when the user attempts to submit the form. Example 2: I'm using the Tongue library to provide client-side translations of the whole UI, but the same data files and library are used in some cases on the server to generate files that contain translated strings. Example 3: The web UI logic is written using pure data manipulation (thank the Re-frame library for that) and because of that we are able to unit test it on the JVM without having to go through the complecity of launching and driving a browser on our CI server.

rubyn00bie 7y ago
Thank you so much for the response! Number 3 has me totally stoked; since that's incredibly valuable-- or like a dream to me to be honest, could you speak more about how that works? Is it just from using re-frame (which I'm looking at as I write this)? Is it able to test for visual regressions because of the pure-data UI? Or like how have you found that testing functionality in practice has it been saving y'all a lot of bugs and headaches you think?
- rufugee 7y ago
  Agreed... would love to hear more about this as well....
  - simongray 7y ago
    Check out my reply to rubyn00bie.
- simongray 7y ago
  The way Re-frame works, almost all of your application logic is represented with immutable tuples and maps (called "events" in Re-frame jargon). The parts that can't be represented this way, i.e. need to access the DOM, are moved to the edges of the codebase and are called "effects" and "coeffects". In practice, 80-90% of your application code can be represented as events, while the remainder becomes effects and coeffects. Your application logic is effectively a finite state machine and you can unit test all of it. The visual part of Re-frame is handled by reagent, which is a minimalist React wrapper that represents React components as pure functions, JSX as built-in Clojure data structures literals (hiccup), and state transformations using Clojure's idiomatic atom data structure. Re-frame builds on top of this base, by enforcing that a single atom (called db) holds all of the state and providing a DSL to create cursors into parts of it. Like most things in Clojure, Re-frame's initial setup is not a straitjacket and you can swap out the state atom with e.g. an in-memory datalog database using posh/re-posh and make the data retrieval completely declarative too.

slifin 7y ago

A lot of Clojure libraries will be described as Clojure(Script) libraries which means they run on both Java and JS usually with no interface changes here are some examples: https://github.com/tonsky/datascript https://github.com/tonsky/datascript https://github.com/Engelberg/instaparse https://github.com/Engelberg/instaparse https://github.com/wilkerlucio/pathom https://github.com/wilkerlucio/pathom Interop with hosts is a core feature of the language so it feels natural to reach for it when you need it and it's easy to write code that handles multiple runtimes but 95% of the time maybe more you don't need explicit runtime features

yogthos 7y ago

My team is developing full stack apps with Clojure, and using Clojure on the backend with ClojureScript on the frontend is completely seamless. I copresented a talk on the platform my team develops and how we leverage Clojure features there, specifically the ability to cross-compile between Clojure and ClojureScript that might be of interest https://www.youtube.com/watch?v=IekPZpfbdaI https://www.youtube.com/watch?v=IekPZpfbdaI