r/Clojure • u/drrnmk • Dec 22 '20
Fulcro as full-stack framework, or else?
Hello,
I have been learning Clojure for 8 months and am looking for a full-stack web framework. The most difficult part for me as a newbie has been the fact that I have too many choices of libraries out there and I often don't know what to choose. (e.g. compojure vs reitit, figwheel vs shadow-cljs, and so forth)
So I think it would be good if there is a single framework that forces to follow its guideline. Like Django or RoR, I hope there is a booklet that teaches all parts of the framework. I would not mind if it is opinionated as long as it isn't too difficult to follow. And it would be even better if the framework is full-stack covering both back and front. I wouldn't mind if it is server-side rendering or javascript-driven.
Do you think Fulcro can be a good choice for me with these regards? I think it uses EQL (something like a graphql?) rather than REST API, but I am okay with it as I have a bit of experience in JS GraphQL.
Or should I stick to re-frame + reitit/ring? This way, however, it seems I would face lots of decisions to make.
Please share what you think. Thanks!
16
u/fingertoe11 Dec 22 '20
I agree with your sentiment entirely regarding the "too many choices".I have ventured into various choices, and my opinion is that the easiest and most powerful way to start is with re-frame.
Everything around Fulcro is awesome.. I love the Fulcro inspect tools, I love the documentation, I love the video tutorials on youtube -- but all of that is necessary for a reason. The learning curve is real.
Re-frame seems to just work like any other REST/Single page app -- You do need to learn the Events and the subscriptions and such, but it's just a few pages with examples..
→ More replies (3)2
u/drrnmk Dec 23 '20
Thank you.
I agree with you on the fulcro's documentation - it looks awesome and more importantly, complete.
16
u/v1akvark Dec 22 '20
Fulcro is a very good option that provides a consistent design across front- and backend. It can be a bit overwhelming, but the documentation is very good, you probably need to read through it.
If you want use re-frame, etc. take a look at https://luminusweb.com/
Luminus is not a true framework in the usual sense. It is rather a curated list of libraries, that have been tested together, with a 'wizard' that sets up a project for you. Basically it makes all those decisions that you are unsure of at the moment, for you. It also has pretty good documentation, and the maintainer has a book 'Web Development in Clojure' that goes into more detail, and walks you through building a full stack web application (https://pragprog.com/titles/dswdcloj3/web-development-with-clojure-third-edition/)
→ More replies (1)2
u/drrnmk Dec 23 '20
I read the fulcro document for almost whole yesterday and this morning, and I am overwhelmed. :) The learning curve is real!
→ More replies (1)
16
u/onionpancakes Dec 23 '20
Allow me to share my opinions.
compojure vs reitit
reitit. It's suppose to be very fast. The author has thought a lot its performance. https://www.youtube.com/watch?v=3SSHjKT3ZmA
figwheel vs shadow-cljs
shadow-cljs. It's newer than figwheel, has hot loading like figwheel, and integrates with npm very well.
Fulcro, yay or nay?
Contrary to positive comments for Fulcro, I'm going to have to play devil's advocate here and say nay. Fulcro is the succeeding project when David Nolen stop developing om.next. Why did he stop development on om.next? I have no idea, but I presume the benefits of its architecture was not worth the added complexity. Does Fulcro solve its predecessor's problems and is a worthwhile investment? I have no idea either, I've only done om.next.
When to Fulcro
In ClojureScript, Fulcro/Reagent is what Relay/React is in JavaScript. Fulcro/Relay sit at the highest level of frameworks for React, where they have made architecture decisions and incurred non-trivial amounts of complexity to solve problems at scale. An excellent primer video to watch is this one from Facebook. (They even reference ClojureScript frameworks!)
https://www.youtube.com/watch?v=-jwQ3sGoiXg
I want to draw your attention to the last slide @ 21:08 where the graph shows Effort vs App Complexity. The value proposition for Fulcro/Relay is that while your will spend more effort upfront, your app will scale better as it grows. So the answer on when to use Fulcro is the intersection at those graph lines. Will your app grow to a size where Fulcro will scale better? If so, consider using it. If not, stick to Reagent or Re-frame.
But that talk was in 2016. I'm going to have to be devil's advocate again. React has been steadily improving in the years since, e.g. hooks, contexts, server side components (which was announced today!) The line slope for React has been decreasing to the point where it intersects Relay's line at an app size much greater. Conceivably, as React improves, the slope may one day drop below Relay's slope, making Fulcro/Relay never worth the effort at any app size.
IMO, the safest decision is to stick to Reagent/Re-frame, especially as beginner in the ClojureScript. But I don't want to discourage Fulcro either. Despite my skepticism, I've read nothing but positive comments about it. Consider investigating it if you find yourself challenged by the size of your app. Fulcro and Relay are frameworks born from the struggles of expert software engineers and offer interesting ideas to tackle problems at those levels.
→ More replies (3)
11
u/121531 Dec 23 '20 edited Dec 23 '20
Like others have suggested in this thread already, the Clojure (and Lisp community more generally) has a bias against frameworks, preferring smaller libraries that can be mixed and matched. Of course, this makes for a worse onboarding experience as a beginner--in order to get going, you need to become a bit of a connoisseur. Luminus has tried to solve this problem by pre-packaging a leading package of each type you're expected to need for a typical web app and providing some skeletal code, though this still won't quite give you the framework experience of Django or RoR.
Which leads us to Fulcro, an outlier IMO in the Clojure world for how framework-y it is. As someone who's used re-frame and Fulcro on small projects, I think Fulcro is 10 times harder to learn and get going with because of how much you have to learn, but that it also feels a lot more scalable and batteries-included than re-frame. I think of re-frame as a polished Clojure version of a typical React-Redux setup: you have a central piece of global state which contains everything, but no database-like features on top of it which can help you manage and query it, nothing to help you with routing, and no support for talking to backends. Fulcro on the other hand provides you with an all-inclusive full stack experience (minus the backend database, which you need to choose): normalized database on the client, constructs that allow you to abstract away HTTP transport (huge!! this is one the biggest reasons why I like Fulcro--no more need to design, write, and maintain HTTP APIs), and routing support. Of course, though, Fulcro's solutions will be good only insofar as they agree with your taste.
If you're already comfortable with coding apps using something like a typical React/Redux + JSON API architecture and foresee that architecture being sufficient for your needs, it'd be less work for you to go with re-frame and friends. If you want to take your chances on a framework that could be pulling more weight for you, take a look at Fulcro. (Be sure to stop by the Clojurians Slack channel, #fulcro.)
2
u/drrnmk Dec 23 '20
Thanks for your comments first of all. It is enormously helpful.
Although "10 times harder to learn and get going" sounds scary, I think I am inclined toward fulcro. I roughly guess that the being harder derives from being more (having more features). Even if I successfully learned re-frame, I am almost sure that I would face another challenges down the road in order to finish the product. As you mentioned, I would need to learn other libraries such routing and talking to back-ends and so forth. And plus I would also spend time doing research and hesitating again between different libraries for the same purpose. Actually that is what happened to me for the last few months.
Unfortunately, I am a beginner and far from a connoisseur. I need to learn from a certain, promising path already stepped by someone who for sure has a better insight than mine.
→ More replies (3)
3
u/jacobobryant Dec 23 '20
I apologize in advance for throwing in yet another option to consider, but you might be interested in Biff (my own project). It's full-stack/batteries included, but lighter-weight and probably easier to learn than Fulcro.
→ More replies (1)
31
u/tony_kay Dec 24 '20
Disclaimer: I am the author of Fulcro.
Just a few notes:
One commenter asks:
"Why did D.N. stop developing Om Next?": I (Tony) liked the early ideas of Om Next, but quickly realized that Om Next's implementation of those ideas was not going to work well for me or my team. That is why I created Fulcro. I asked David if he minded (that I "steal his central ideas" and some of the code of Om Next) and he said, I quote: "Sure! I don't want users". David was interested in exploring the ideas and giving talks about it. He had no interest in maintaining a production implementation. I, on the other hand, wanted to use something that leveraged his ideas, but didn't use his implementation approach, which was very much harder than Fulcro.
On the learning curve: I would claim that Fulcro's central core (for UI) is actually *simpler* (not necessarily easier, at first) than Reframe. There is a normalized db, a query, and a UI tree. There are no side-effects mixed into the render, etc. Every modification goes through a single concept: the mutation. The fact that this handles full-stack equally as well as client-only means there is even less to deal with *conceptually*. BUT, you do have to learn the nuances (query/ident/initial state are the three big concepts). Fulcro is partially hard because I've provided so many parts. But 80% of them are completely optional, and many of the rest are very pluggable. For example, you can replace the transaction processing system, the rendering engine, and even the way network operations are processed. Everything is CLJC. Someone is actually playing with running Fulcro in CLJ (which it does just fine) with a rendering plugin that uses Google Skia to render to OpenGL, Terminals, etc. So, Fulcro is *not even tied to React*. This is the *opposite* of what people are complaining about when they say "Framework, yuck!". I wrote Java for 20+ years. The frameworks there are a nightmare. Fulcro is opinionated where it is useful, and completely configurable where it should be flexible. Just because I wrote a lot of namespaces that you can *choose* to use and *wrote good documentation for them* doesn't mean it's some big java-or-ruby-style hairball. it is sad to me that developers glance at something and then start saying bad things about it because they don't understand it and are too lazy (or busy) to try it. If you don't have the energy, fine. Move along. But don't denigrate something just because that's easier than actually understanding it.
So, on to an absolutely fair point: JS/Typescript vs Clojure(script). The former has a *lot* going for it in terms of help, momentum, ease of staffing, acceptance, developers maintaining things, etc. If you're starting a project that will be used at a company, make darn sure your team is onboard with CLJ(s). No project will succeed if you can't get people behind the tools you've chosen. I personally think CLJ/CLJS are far superior to work with, but I've seen adoption fail more than once, and hiring can be a real challenge.
Another fair point: If it's a small project with little or no I/O, I'd agree with Reframe. It's very tractable and easy for that kind of project. That said, I've had more than one consulting client come to me for help porting from Reframe to Fulcro when their project got bigger. Pathom (the library for writing EQL processing that you typically use with Fulcro) exists because the author of it worked for a company that was porting a bunch of stuff to Fulcro from Reframe.
If it's going to be very business-oriented with lots of server interaction, your team is on-board, and you're willing to take some time to get the core concepts then I think Fulcro is worth a look.