4 ms·

Fulcro is also worth a look. I've been using it for a few projects and have been happy with it so far.

capableweb 7y ago
Haven't myself dived into Fulcro too much (mostly do ClojureScript so don't need the full stack) but always found interesting ideas to borrow from. Especially around the UI State Machines that they have lots of docs around. http://book.fulcrologic.com/#_ui_state_machines http://book.fulcrologic.com/#_ui_state_machines
Folcon 7y ago
I've been trying it out as well, enjoying it so far. Link: https://fulcro.fulcrologic.com/ https://fulcro.fulcrologic.com/
- mping 7y ago
  I tried fulcro but the amount of concepts you needed to learn was a bit too much. Unfortunately I was experimenting with electron which made it more complicated. It sounds a great framework if you have the right requirements but personally I found reagent/reframe alot simpler for my use case. Also, the fulcro docs are thorough but it didn't click for me, I left with some questions unanswered.
  - Folcon 7y ago
    That I can agree with, I use re-frame quite a bit in my day job, it's straightforward and lets you get things done. I'm also of the opinion that the Fulcro docs are very substantial, but aren't always easy to get your question answered. I've been blogging little bits and pieces of things that I've figured out that I don't think were super easy to discover, considering the amount of work that's gone into it, I'm hopeful that the situation will improve. However it's an interesting change to see something designed that's trying to be a complete end to end solution, take the new RAD tools for example[0], there's some cool stuff going on there. There's a demo[1] available as well. - [0] https://github.com/fulcrologic/fulcro-rad https://github.com/fulcrologic/fulcro-rad - [1] https://github.com/fulcrologic/fulcro-rad-demo https://github.com/fulcrologic/fulcro-rad-demo
    - mping 7y ago
      Will take a look, tks
    - subsaharancoder 7y ago
      Re-frame is enjoyable and the concepts are straightforward, unfortunately Fulcro suffers from the same problem as Om which is that the concepts just make you feel stupid..
    - mping 7y ago
      Hey, where's your blog? I'd like to take a look at those bits too!
      - Folcon 7y ago
        folcon.github.io :)...
  - ballpark 7y ago
    I find myself going to the youtube videos a lot. There's a lot of new concepts in Fulcro. I'm surprised how long it's taking me to figure it out, but I haven't given up yet, and so far I'm liking it. I'm hoping that the investment proves worthwhile.
    - mping 7y ago
      I saw the videos, they are helpful but I couldnt make my project work somehow.
      - ballpark 7y ago
        I get it. Also, the community is active in their Clojurians Slack channel #fulcro
tvaughan 7y ago
We just re-evaluated our choices and selected Fulcro. Below is a slightly edited version of how we came to this conclusion. As a business building an extremely ambitious product on a tight budget, we want to be able to: * Focus as much time and thought on building features that bring value to our customers, rather than, for example, building a bespoke protocol between the browser and back-end if a better alternative is available. * Share early iterations of our application with everyone in our organization easily. Capture feedback and push out new iterations quickly. * Be able to support new customers immediately. Our feature road-map will always be in constant flux, but at no point should our ability to make changes with confidence be compromised. In addition to feature development, tests and automation must be priorities. Our development and production environments must match. * Be ready to onboard new team members. "Works on my laptop" is never acceptable. Enough of our application must be documented and automated so that anyone with a technical background "reasonably proficient" in our work can contribute without requiring hand-holding. Or course, we'd never turn down a request for help. Our requirements are: * Clojure, Clojurescript, and Datomic are immutable choices. We love these solutions for their simplicity and expressiveness. We believe these are the best choices available for achieving our long-term business goals. * Be measurable. Our work should be guided by data not guesswork. * Be testable. The entire application should have 100% test coverage as measured by its acceptance or integration tests (not unit tests). Changes should be made with confidence. * Be performant. As builders of both the front-end and back-end components, we should encourage cooperation between them, not purposefully isolate them. Our customers and the end-user experience should be our priorities, not artificial divisions between software components or technical teams. Each component of the application should cooperate to support progressive enhancement where every URL is a real URL that, when requested, returns a server-side rendered page view. Further actions by the user result in browser-side changes through API calls and minimal component updates. * Be pragmatic. We should be eager to innovate when the need arises. However, we should be humble enough to understand that sometimes, as software developers, we can become enamored with new toys that are entertaining, and possibly educational, but offer little business value. We should choose existing solutions to our problems that are acceptable enough over building our own solutions simply because we want to. For example, a standards-based protocol, like https://github.com/edn-query-language/eql https://github.com/edn-query-language/eql, that allows clients to craft their own queries with little to no server-side updates is preferable to our current bespoke solution. * Be documented and supported. Our choices should have active, helpful, and inclusive development communities built around them. Our choices are: * Rum, https://github.com/tonsky/rum https://github.com/tonsky/rum Rum is a solid piece of software, created and maintained by @tonsky, that provides a minimal wrapper around react for creating client-side components, and supports server-side rendering. Although rum does not provide a protocol between client and server, nor a client component state-management solution. * Reagent, https://github.com/reagent-project/reagent https://github.com/reagent-project/reagent Together with Re-frame, https://github.com/Day8/re-frame, this is by far the most popular choice for building reactive client components in Clojurescript. These do not include the server-side solutions we need. * Hoplon, http://hoplon.io http://hoplon.io Hoplon was created in-house at AdZerk, and later spun-out as an open source project. Hoplon is a complete solution although it uses a less intuitive spreadsheet-like method for building applications with little obvious advantage, and would not be compatible with Datomic without considerable effort. * Luminus, https://luminusweb.com https://luminusweb.com Luminus is a complete solution like Ruby-on-Rails, and is tightly coupled to SQL. Like Hoplon, Luminus would not be compatible with Datomic without considerable effort. * Pedestal, http://pedestal.io http://pedestal.io Pedestal is supported by Cognitect, the custodians of Clojure and the creators of Datomic. Except Pedestal is best suited for building server-side APIs, and applications that need to stream data in "near real-time" to large numbers of concurrently connected clients. * Fulcro, https://fulcro.fulcrologic.com/ https://fulcro.fulcrologic.com/ Fulcro is based on Om.Next, provides both front-end and back-end components that work well together, includes tools for building and debugging both, supports server-side rendering, and is supported by a diverse community. Paid commercial support is provided by the core developer team at Fulcro Logic. * Datomic Cloud, https://www.datomic.com https://www.datomic.com Datomic Cloud is a special version of the Datomic database that is tightly integrated with AWS. Datomic Cloud includes a set of Cloud Formation templates for running Datomic in AWS, and taking advantage of AWS specific features, such as auto-scaling groups and load-balancers for distributing traffic across a cluster of Datomic peers. Datomic Cloud also includes Ions, https://docs.datomic.com/cloud/ions/ions.html, to help run Clojure functions as AWS Lambdas. Cognitech claims Datomic Cloud is a suitable framework for building complete applications. Unfortunately Datomic Cloud alone is insufficient. Datomic Cloud lacks a framework for building and testing client-side applications, and a protocol for interacting with Ions.

Haven't myself dived into Fulcro too much (mostly do ClojureScript so don't need the full stack) but always found interesting ideas to borrow from. Especially around the UI State Machines that they have lots of docs around. http://book.fulcrologic.com/#_ui_state_machines http://book.fulcrologic.com/#_ui_state_machines

Folcon 7y ago

I've been trying it out as well, enjoying it so far. Link: https://fulcro.fulcrologic.com/ https://fulcro.fulcrologic.com/

mping 7y ago
I tried fulcro but the amount of concepts you needed to learn was a bit too much. Unfortunately I was experimenting with electron which made it more complicated. It sounds a great framework if you have the right requirements but personally I found reagent/reframe alot simpler for my use case. Also, the fulcro docs are thorough but it didn't click for me, I left with some questions unanswered.
- Folcon 7y ago
  That I can agree with, I use re-frame quite a bit in my day job, it's straightforward and lets you get things done. I'm also of the opinion that the Fulcro docs are very substantial, but aren't always easy to get your question answered. I've been blogging little bits and pieces of things that I've figured out that I don't think were super easy to discover, considering the amount of work that's gone into it, I'm hopeful that the situation will improve. However it's an interesting change to see something designed that's trying to be a complete end to end solution, take the new RAD tools for example[0], there's some cool stuff going on there. There's a demo[1] available as well. - [0] https://github.com/fulcrologic/fulcro-rad https://github.com/fulcrologic/fulcro-rad - [1] https://github.com/fulcrologic/fulcro-rad-demo https://github.com/fulcrologic/fulcro-rad-demo
  - mping 7y ago
    Will take a look, tks
  - subsaharancoder 7y ago
    Re-frame is enjoyable and the concepts are straightforward, unfortunately Fulcro suffers from the same problem as Om which is that the concepts just make you feel stupid..
  - mping 7y ago
    Hey, where's your blog? I'd like to take a look at those bits too!
    - Folcon 7y ago
      folcon.github.io :)...
- ballpark 7y ago
  I find myself going to the youtube videos a lot. There's a lot of new concepts in Fulcro. I'm surprised how long it's taking me to figure it out, but I haven't given up yet, and so far I'm liking it. I'm hoping that the investment proves worthwhile.
  - mping 7y ago
    I saw the videos, they are helpful but I couldnt make my project work somehow.
    - ballpark 7y ago
      I get it. Also, the community is active in their Clojurians Slack channel #fulcro

tvaughan 7y ago

We just re-evaluated our choices and selected Fulcro. Below is a slightly edited version of how we came to this conclusion. As a business building an extremely ambitious product on a tight budget, we want to be able to: * Focus as much time and thought on building features that bring value to our customers, rather than, for example, building a bespoke protocol between the browser and back-end if a better alternative is available. * Share early iterations of our application with everyone in our organization easily. Capture feedback and push out new iterations quickly. * Be able to support new customers immediately. Our feature road-map will always be in constant flux, but at no point should our ability to make changes with confidence be compromised. In addition to feature development, tests and automation must be priorities. Our development and production environments must match. * Be ready to onboard new team members. "Works on my laptop" is never acceptable. Enough of our application must be documented and automated so that anyone with a technical background "reasonably proficient" in our work can contribute without requiring hand-holding. Or course, we'd never turn down a request for help. Our requirements are: * Clojure, Clojurescript, and Datomic are immutable choices. We love these solutions for their simplicity and expressiveness. We believe these are the best choices available for achieving our long-term business goals. * Be measurable. Our work should be guided by data not guesswork. * Be testable. The entire application should have 100% test coverage as measured by its acceptance or integration tests (not unit tests). Changes should be made with confidence. * Be performant. As builders of both the front-end and back-end components, we should encourage cooperation between them, not purposefully isolate them. Our customers and the end-user experience should be our priorities, not artificial divisions between software components or technical teams. Each component of the application should cooperate to support progressive enhancement where every URL is a real URL that, when requested, returns a server-side rendered page view. Further actions by the user result in browser-side changes through API calls and minimal component updates. * Be pragmatic. We should be eager to innovate when the need arises. However, we should be humble enough to understand that sometimes, as software developers, we can become enamored with new toys that are entertaining, and possibly educational, but offer little business value. We should choose existing solutions to our problems that are acceptable enough over building our own solutions simply because we want to. For example, a standards-based protocol, like https://github.com/edn-query-language/eql https://github.com/edn-query-language/eql, that allows clients to craft their own queries with little to no server-side updates is preferable to our current bespoke solution. * Be documented and supported. Our choices should have active, helpful, and inclusive development communities built around them. Our choices are: * Rum, https://github.com/tonsky/rum https://github.com/tonsky/rum Rum is a solid piece of software, created and maintained by @tonsky, that provides a minimal wrapper around react for creating client-side components, and supports server-side rendering. Although rum does not provide a protocol between client and server, nor a client component state-management solution. * Reagent, https://github.com/reagent-project/reagent https://github.com/reagent-project/reagent Together with Re-frame, https://github.com/Day8/re-frame, this is by far the most popular choice for building reactive client components in Clojurescript. These do not include the server-side solutions we need. * Hoplon, http://hoplon.io http://hoplon.io Hoplon was created in-house at AdZerk, and later spun-out as an open source project. Hoplon is a complete solution although it uses a less intuitive spreadsheet-like method for building applications with little obvious advantage, and would not be compatible with Datomic without considerable effort. * Luminus, https://luminusweb.com https://luminusweb.com Luminus is a complete solution like Ruby-on-Rails, and is tightly coupled to SQL. Like Hoplon, Luminus would not be compatible with Datomic without considerable effort. * Pedestal, http://pedestal.io http://pedestal.io Pedestal is supported by Cognitect, the custodians of Clojure and the creators of Datomic. Except Pedestal is best suited for building server-side APIs, and applications that need to stream data in "near real-time" to large numbers of concurrently connected clients. * Fulcro, https://fulcro.fulcrologic.com/ https://fulcro.fulcrologic.com/ Fulcro is based on Om.Next, provides both front-end and back-end components that work well together, includes tools for building and debugging both, supports server-side rendering, and is supported by a diverse community. Paid commercial support is provided by the core developer team at Fulcro Logic. * Datomic Cloud, https://www.datomic.com https://www.datomic.com Datomic Cloud is a special version of the Datomic database that is tightly integrated with AWS. Datomic Cloud includes a set of Cloud Formation templates for running Datomic in AWS, and taking advantage of AWS specific features, such as auto-scaling groups and load-balancers for distributing traffic across a cluster of Datomic peers. Datomic Cloud also includes Ions, https://docs.datomic.com/cloud/ions/ions.html, to help run Clojure functions as AWS Lambdas. Cognitech claims Datomic Cloud is a suitable framework for building complete applications. Unfortunately Datomic Cloud alone is insufficient. Datomic Cloud lacks a framework for building and testing client-side applications, and a protocol for interacting with Ions.