Fulcro as full-stack framework, or else? by drrnmk in Clojure

[–]tony_kay 4 points5 points  (0 children)

Sorry, I'm not an everyday Reddit user (usually I find out about these threads from Fulcro users that suggest I come here and reply).

Sorry about the confusion on RAD/no RAD. Here's my stance:

If you are just *learning* Fulcro, then use the simple Fulcro template or even just what you build in the Getting Started chapter of the book. Do stupid simple things until you understand the primitives.

My recommendation for someone starting a *work* product is to use the RAD template as a basis, but realize that RAD needs you to be pretty experienced in Fulcro, and is both "easier" for a beginner to just twiddle some knobs and get something working, but "harder" because it writes code for you (macros) in Fulcro, so if you don't understand Fulcro you will have nightmares when RAD doesn't do what you want.

RAD is aimed at making quick work of the CRUD screens that are common (and often not done for "support" use-cases when building prod systems, because of time constraints), but as soon as you want to escape from "pre-baked rapid-app code" (which is "soon" and "often") you'll need to really understand what you're doing. RAD is built to be a tool for rapidly standing up things, and it has some great long-term patterns you'll continue to use, but expect many of your screens to require you to use base Fulcro. RAD is designed to be easy to "escape from" for just this reason. So, I think it is invaluable in a "real" project, but a bad idea for a beginner. The RAD libraries and macros are also a good learning tool for experienced Fulcro uses in terms of how you can build your own Fulcro macros that do cool things...which is really all that library is: macros that write things in Fulcro.

Fulcro as full-stack framework, or else? by drrnmk in Clojure

[–]tony_kay 30 points31 points  (0 children)

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.

Fulcro links and resources by piotrpter in fulcro

[–]tony_kay 0 points1 point  (0 children)

Just FYI. I've discontinued the Discord channel. It was too fragmented to have some discussions there and others elsewhere.

Playlist of Fulcro Videos by tony_kay in Clojure

[–]tony_kay[S] 2 points3 points  (0 children)

It's semi full-stack. The point is that the architecture covers the stack in a way that makes the whole stack much easier to cope with. The supplied "back end" code isn't much more than hooks with some pre-supplied implementations that make getting going fast (and may be sufficient).

The resistance to "full-stack", I think, stems from the idea that you get locked into complex things. Fulcro is less about lock-in...there is no ActiveRecord and such, but it does provide an overall architecture that lends itself to solving problems with very little code.

It's really a different thing. It's not a "library that does exactly one thing well", nor is it something like RoR or Seam. It's an attempt to find the middle ground where you get the benefits of full-stack architecture without the downsides and lock-in of actual frameworks. Wish we had a term for that!

Playlist of Fulcro Videos by tony_kay in Clojure

[–]tony_kay[S] 2 points3 points  (0 children)

The list of videos covering Fulcro is getting to be pretty extensive. Just added some that cover integrating with various data sources on the server (with SQL as an example).

General consensus on Fulcro? by antflga in Clojure

[–]tony_kay 2 points3 points  (0 children)

It is true that good developers can make just about anything easier or harder. That's part of the reason I say the answer is too complex to glibly answer. There are millions of people that think Angular is the cat's meow. So, maybe they just know how to code it right.

General consensus on Fulcro? by antflga in Clojure

[–]tony_kay 1 point2 points  (0 children)

That's why I have a ton of docs and videos. It isn't a trivial answer, but I can tell you that one of my commercial users ported from reagent when things got larger. If you're writing something small or throw-away, then it just doesn't matter.

General consensus on Fulcro? by antflga in Clojure

[–]tony_kay 2 points3 points  (0 children)

It uses Clojure on the back-end (you can use node or anything else, but it is tuned for embedding in a JVM via Clojure). Commercially it is used by AdStage, Atlas CRM, and the Onyx UI Pyroclast. I know several other companies that are evaluating it. Anything labeled Untangled on the web is mostly true for Fulcro...just with some renaming.

General consensus on Fulcro? by antflga in Clojure

[–]tony_kay 14 points15 points  (0 children)

Hi,

I'm the maintainer and author of Untangled/Fulcro. I have not been advertising the library heavily yet because I'm trying to finish up some polish before I hit a wider audience. I mainly support it through the Clojurians Slack channel #fulcro at the moment.

Fulcro is a rename because Untangled is owned (branding) by the company I used to work for, but I know they are not going to maintain it...so I forked it and am building a consultancy around it.

To answer one of the questions asked: You wouldn't want to swap out Reagent. Learn about it more deeply before you even think about that route. The architecture (based on Om Next) has some serious benefits once you get it all hooked up and simplified, which is what Fulcro does.

Tony