This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # beginners (32)
- # boot (15)
- # cljs-dev (200)
- # cljsjs (1)
- # cljsrn (18)
- # clojure (4)
- # clojure-austin (2)
- # clojure-spec (6)
- # clojure-uk (8)
- # clojurescript (69)
- # cloverage (1)
- # cursive (12)
- # datomic (1)
- # dirac (37)
- # emacs (1)
- # hoplon (38)
- # off-topic (3)
- # om (19)
- # om-next (1)
- # onyx (4)
- # parinfer (2)
- # perun (27)
- # protorepl (4)
- # re-frame (5)
- # rum (9)
- # spacemacs (8)
- # untangled (2)
Hey y’all. 🙂 Quick non-scientific poll question: I’m starting a new ClojureScript project with Om Next, and haven’t really been able to find any new blog posts, Reddit threads or tweets on the best Clojure server-side framework for React/React-Native CLJS apps as of late 2016. I did see both the Om Next demo, CircleCi’s frontend and the Precursor app now open-sourced all use Ring. But I’m not sure if there’s a general consensus now given all the activity in the community as of late, if one were to start a new Om Next project from scratch, what the simplest (in Rich Hickey/David Nolen terms) framework of choice is now. Pedestal has the backing of Cognitect, Arachne is almost ready for alpha, and new things like Duct and Luminus have popped up, etc. Thoughts on if Ring is still the way to go? Would seriously appreciate any input for a newbie. 🙂 Thanks in advance!
Added: My intuition is to trust whatever Cognitect is backing. Counterargument I guess would be to use whatever is the most composable, which sounds like it’s Ring given the amount of available libraries, and more are getting made all the time. Kind of like the Boot > Leiningen argument for long-term projects. But are Pedestal’s opinionated design choices good, like Om Next’s are good? I’m delving more into the docs now but would love input if any of y’all have already made your own decisions on this for your own projects. 🙂 Additional context: I’m hoping to scale this particular project in the context of a hopeful startup. So without overengineering, I would kind of like to think long-term, but also something hopefully both simple and easy for a beginner like me.
More context: The high-level concept I’m working on is to essentially build “Reddit meets Snapchat stories and Tinder” for creating project-based communities around video tutorials on any subject (like building flying cars, or making rap beats, or a new VR video game), and then try and connect people physically who are near each other’s locations and want to make the same cool things together in person. So architecture wise, I’ve been looking into separating a lot of the different backend pieces via microservices in Dockerized containers all connected by Clojurized/EDNized APIs. Which it sounds like Pedestal is sort of designed for out-of-the-box.
@keatondunsford I am not sure about the backend stack, for my private stuff I stayed with http-kit for the last years, but ring is surely similar / better as well. For my next project I wanted to look at pedestal too. I hope they got its documentation sorted out inbetween, which kept me back 3 years ago. For the frontend side I found reagent easier to understand than Om. Given that you say there are not much tutorials out there for Om.next you might be better off with reagent which is API stable for several years now and has a relatively big support in the community. That said, I totally like what David Nolen does and would experiment with Om.next too, just out of curiosity.
Also, will that be open source? I have been tinkering with a similar idea in my head for a long time too. Especially the part where you connect local people is important to me. This is something that many platforms dont seem to think of from the start
For my use case, the GraphQL/Falcor side of things is a huge value proposition I can’t ignore. Also, after delving into the tutorials, I actually think Om Next is more simple, in the Clojure-world definition of “simple”. I love the abstraction of the reconciler and treating application state as one giant immutable data structure. This blog post by CircleCI really sold me on it: https://circleci.com/blog/why-we-use-om-and-why-were-excited-for-om-next/
I’ve been debating open-sourcing it, but I gotta think about it for a little longer. 🙂
I read that article too and the idea of having something similar to graphql is great. But, I was following Om along and used it for some time. The thing is, David has only so much time and he uses most of it for clojurescript, so my experience with om was, that it was good to use as it was, but only few advancement happened, and I fear it will take a long time for om.next to be production ready and have an ecosystem evolved around it. But thats just my subjective fear based on things that happend some time ago and times change, so it might be different now
We built small systems in Om and then Reagent -- and we liked Reagent a lot better. We haven't yet tried Om.Next. I've seen some of the presentations -- including one in person -- and I have to admit that I just don't get it. So I'll probably stick with Reagent and maybe re-frame. We like Sente as well (and used it with Reagent).
These may be what you want Reader: https://clojuredocs.org/clojure.java.io/reader InputStream: https://clojuredocs.org/clojure.java.io/input-stream
Clojure relies on the host (Java) for I/O so you will need to learn a bit of the Java API for this
But is this really the right way to do it? I mean, for a serious language, shouldn’t it have its own way to do all the common tasks, like reading a binary file?
There's a good example here https://github.com/clojure-cookbook/clojure-cookbook/blob/master/04_local-io/4-19_handle-binary-files.asciidoc
Clojure encourages to call directly to Java library for things which aren’t too verbose. Wrapper may come with a cost of unnecessary complications and performance penalty
@markx, I think you may be waiting a while 🙂 One of the benefits of Clojure's JVM integration is all the free stuff you get from Java's ecosystem (and correspondingly the JS one for cljs). You can definitely get productive in Clojure without being expert in Java, you'll just end up incidentally knowing some elements along the boundary and knowing how to read a Java stack trace.
@markx I don't think you need to learn 'Java' at all as there are Clojure wrappers around most Java classes. As @bwstearns states you may need to understand a stack trace (but true of a number of languages) and with Clojurescript you need to understand some JS not Java. I can't see Rich ever moving off the JVM as most of the advantages are it's a hosted language. If you really can't stand JVM you can run ClojureCLR and run on the .NET common language runtime!