It sounds pretty good. "Unscaryfying" and this sentence are a little bit awkward to me: > Stop choosing "simpler" web frameworks - and ending up implementing half of Fulcro with much more effort and verbosity and much less value.

I would also suggest a positive tone/wording vs a not-negative tone/wording - "Understanding Fulcro in 3 easy pieces" "Fulcro demysitified" or something like that For example, let's say I have never heard of fulcro and I see this talk title. Now I have an association that it is scary - and in the description "complicated and scary" - Instead I think these sort of counter-points can go in the talk itself, as a minor note to rebut anyone who has that perception. If I was perusing talks I would want to know more about what I'll be learning. Actually describing some of the content: what is the minimalist approach? seeing things like "ident, query, normalization" etc would give me more details - reading this description I ask myself: "What are the three corner stones?, what are the bulding blocks?" a few more words about that would help me understand what I'll be learning. Hope that helps!

Is demystifying any different from the positive/negative side than, unscaryfying, though?

I forget @U0522TWDA have you used re-frame? I imagine this sort of talk about fulcro would likely target people who use re-frame. Learning more about it would help make stronger arguments about how fulcro can help you solve problems you'll find yourself dealing with in re-frame.

@U8ZQ1J1RR yep, you could say so, how about the first suggestion then : )

Thank you, great points! I will try to incorporate them. Though I really like "Unscaryfying". It is a weird word and will attract attention (though you might be also right that it will rather detract it 😅 ) @UPWHQK562 what about > Stop choosing "simpler" web frameworks - and ending up implementing half of Fulcro with much more effort and verbosity and much less value. is unclear? The proposition is that people choose frameworks that look simpler (easier?) but eventually run into their limitations and need to implement themselves what Fulcro has built in. I have used re-frame but it way too long. I should refresh my knowledge...

It isn't unclear, especially because we know what you mean 🙂 It's a fine line of providing too much detail and not enough. You're basically saying "batteries included". Can you elaborate on which features Fulcro has built in that is missing in other frameworks/libs? From my perspective - coming from Django - it's not so much about Fulcro's feature set as it as about its unifying graph-based approach to everything.

sounds good, I'm looking forward to the talk 🙂

@U0522TWDA I am planning to attend :clojureD too. Finally an in-person conference again! I want to emphasise what's already said. Wenn talking with colleagues and friends, I often get a sceptical response to Fulcro: „Too hard, too complicated, too much“ They use re-frame, simply because it's easier to learn and has a larger community. So a comparison to other technologies is most welcome. What are drawbacks, where are the strengths of Fulcro? When too use it, when to avoid it? What are the hurdles you can (and probably will) encounter? (Not only Fulcro, but re-frame and others.)

Thank you. The „Too hard, too complicated, too much“ is exactly what I want to dispel as a myth.

> Stop choosing "simpler" web frameworks - and ending up implementing half of Fulcro with much more effort and verbosity and much less value Is this https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule of lisp web applications? 😜 Jokes aside (and not directly related to your question): I still think a point worth hammering home is that fulcro has several parts (UISM, Routing, forms, rad....) that in essence are addons to fulcros core. However, when you're starting out and choose for example the fulcro-rad-demo as a starting place for your journey, you simply get thrown into the deep end and you will get lost if you have no previous experience with it / don't know the concepts yet. And this (in my opinion) is where potential users "get scared".

You can get a better idea of the talk if you look at the current https://docs.google.com/presentation/d/1SSnJx-R-P575qdkTtq5H-hdQoxxqmQXW0-WfmecGyLg/edit?usp=sharing > fulcro has several parts (UISM, Routing, forms, rad....) that in essence are addons to fulcros core. yes, I mention that in the talk (page 8 ). Thank you! IMO Fulcro itself is "scary" enough with many hundreds of pages of the dev guide and tons of features you don't need (until you do - then they are gold). That's why I created the minimalist series. (And yes, it was a play on Greenspun of course :))

I often thought about that… Fulcro has so many parts. Maybe it would be better to actually "sell" them as parts. Make the "core" as easy as possible, and then "offer" solutions. RAD is such a thing for me. I used fulcro before RAD, so my code was already in place. I have RAD as a dependency now, but I use only the pathom stuff. I don't use Datomic as a backend, I don't use semantic-ui in the frontend. Nonetheless, I am "scared away" from RAD, although I know, that I am not locked into this.

I think there might be a loop of things that lead to "fulcro is hard and scary" 1. It's not the easiest. (Note: easy ≠ simple) 2. Because of that, people tend to look for "already done" solutions, instead of rolling their own. 3. Which leads to less diversity in the choice people can make. Which supports Point 1.

@U0522TWDA Can you allow comments for your Slides?

Excellent idea thank you! Done.

You mean by point to that they look at Routing when they need routing and Forms State when they need to edit data and discover there is a lot to learn, instead of doing something simple (and less powerful) themselves? I notice that with routing, that in some cases a DIY routing with (case route :a (ui-child-a a-props) ,,,) is simpler and good enough.

I would advise not framing Fulcro as "scary". That rhetoric only works for things, that are scary and people need to deal with it. "Make updates to your production system less scary." That would be alright, because people need to do these updates. For something that people are just considering using, "scary" implies uncertainty and risk.

To remove uncertainties, I would go the way to explain: What is different? Why is it different? What are the advantages of that being different? Example: The dom macros. (dom/a {:href ... vs [:a {:href ... Why macros, instead of a DSL? What are the gains from these macros? Are there doubts, you can lift?

@U0522TWDA It really depends on what you want your talk to be. It's like building software. Who is your audience? People how already know and tried fulcro and weren't convinced? • I guess that would be a small portion of the audience. People who have written SPAs in ClojureScript? • They will compare you to re-frame or whatever they used. People who have written SPAs, but not in Clojurescript? • They will know the pain points People how want to write SPAs, but never did? • They will not even know om.next. • They won't know what "sustainable development of real-world web apps*" mean* When it comes to re-frame: You will not be able to avoid comparisons with re-frame. Maybe present a current re-frame stack and show pain points in there. Show, what ideas in fulcro can eliminate these pain points.

Awesome ideas, thank you! I am trying to frame fulcro as non-scary, dismantling some people's wrong ideas about it 🙂 Ie "you might think it is scary but actually it is not, see why"

The audience is anyone interested in building SPAs in Cljs. I will of course explain what "sustainable development of real-world web apps" means and why it matters, the slides are just points for me to elaborate.

Something like "user friendly" is a different way of saying that it's not scary :man-shrugging:

My colleague just said: > The question that needs to be answered is: why not re-frame?

To offer a counterpoint, I've never used re-frame and don't really know anything about it. Any points along the lines of re-frame would not resonate with someone like myself.

I guess being a Clojure conference, most SPA devs will have some knowledge of re-frame though.

> The question that needs to be answered is: why not re-frame? Indeed. I hope that pages 8+9 answer that

Re-frame does view rendering and state management. Fulcro also does data loading and a whole lot more - that you end up needing earlier or later. Plus, Fulcro's state mgmt is fundamentally simpler - Root gets a tree of data and that's it. No each component reaching into the global state to pluck whatever it wants in a most unpure way 🙀 Of course I could phrase that more user friendly 🙂

BTW if nay of you has extensive experience with re-frame then please provide some tips for comparison 🙂

Not to siderail you current conversation guys, but if you go down the "why not re-frame" route, keep in mind that there are experiments and multiple statements out there where fulcro is only used for state management and the rendering is done by something else. Also, this: https://www.youtube.com/watch?v=ng-wxe0PBEg&t=1392s

How about "Finding Fulcro - embracing the web framework you never knew you needed", popped into my mind. Cfr. the book "Finding Ultra" by Rich Roll (https://www.amazon.com/Finding-Ultra-Revised-Updated-Discovering/dp/0307952207). It has a ring to it, no? 😉

What is a good word for "making approachable" (instead of Unscaryfying / Finding)?

Or Fulcro made Easy 😹

Disarming 😆

Inviting?

some ideas for answering the question "why not re-frame?". go through the blog series here (https://purelyfunctional.tv/guide/state-in-re-frame/) and do a comparison with fulcro. for example • normalized db handled for you: https://purelyfunctional.tv/guide/database-structure-in-re-frame/ • optimistic updates handled for you: https://purelyfunctional.tv/guide/optimistic-update-in-re-frame/ • handling input forms - you'll roll your own in re-frame or use a lib • communicate with a backend (roll your own - what about failures? what about multiple backends? what about combining requests?) • similar: dispatch abstraction to move to the next app state • not similar: rendering is push in fulcro (event->ui) instead of pull (reactive) in re-frame (subscription triggers re-rendering) • ui library: you have any options you want in fulcro, anything that will give you react elements (you can even use reagent) - re-frame requires reagent due to the reactive model • dealing with asynchronous event logic - very painful in re-frame and hard to reason about anything with over a few states (this is a recommended lib, which I have seen not recommended in clojurians re-frame slack: https://github.com/day8/re-frame-async-flow-fx) vs in fulcro - you just dispatch more transactions - from on-success/on-failure handlers and then the obvious - there is no server-side story in re-frame all of these are tradeoffs so depending on what you are trying to build you can argue for or against them, so in a talk about Fulcro I would expect to see the point of view where I have a problem(s) that fulcro can solve and now I want to know how to go about that and how it can help me. My general take on fulcro is that it has a high learning curve with the payoff being that you can create things that are hard or impossible without it, or you would end up re-creating fulcro yourself anyway, so just use it instead 😄

So I will chip in some info that may or may not be useful, but it is historical: When I originally built "Untangled" I broke all of these "parts" into separate libs. There was untangle-client, untangled-server, etc, etc. It was a nightmare to maintain all the libs/versions (dynamic routing, UISM, dom, etc....those "should" all be libs). Futhermore, the cljs compiler does DCE, so splitting them apart didn't buy me anything but hassle and some positive public relations. I knew the community prefers small little libs that do one thing well. I appreciate the general idea there, but I disagree that that is always "good". Sometimes the minimum critical mass of a thing is just "bigger", and for my purposes (which is the reason Fulcro exists) I wanted to spend my time on things that mattered: documentation, functionality, etc. Not releasing 20 little libs that made no substantive difference other than someone being able to say "look, it's really small!". So, I stopped wasting my time trying to please that aesthetic. I understand that means people will still pick Re-frame for 90% of projects. Not sure how to integrate that into a talk. Perhaps you'll make some headway. If I were a skeptic that is hearing "it is hard" then I'm not sure what kind of title would appeal to me most...perhaps "Fulcro: It's way easier than you've been led to believe".

Thanks a lot for the excellent input and ideas, @U051V5LLP! And thanks Tony for the history etc. It certainly makes sense to make that F is a single lib and I believe it is more ergonomic to use it that way, not just the release process. I like the title idea, I will add it to my brewing pot 🙂 I still would like to include something like "the web framework you didn’t know you needed" in the title so I need something shorter 😅

@U0CKQ19AQ I didn't mean to imply that fulcro should be broken in pieces, but that it (maybe) should be sold(/taught) in pieces. I suspect, people looking at fulcro with an inexperienced eye, have a hard time "seeing" the pieces. They see "everything" and are overwhelmed. They tinker with pieces, they are not ready for, but have the impression that they have to because it's "the fulcro way", and are burning their fingers. Sure. Some people have the experience to see all the pieces and can connect them with the problems they solve right away. ---- Maybe the following statement is true: "Fulcro solves problems that most people didn't even realize they have/will have." That lead to my train of thought, about perhaps it would be a great way of teaching (giving a talk about) fulcro piece by piece. Letting the audience discover the issues they will have at their own time and then swoop in and offer a solution. Presenting solutions for problems people don't even have (yet), may be the wrong way round.

I was not thinking you wanted me to…it’s just a PR pain-point in this community 🙂 But it is true that having it all sitting there is initially daunting…what do you use? What is important? People think in terms of “features” (ui routing is a really common one they want first-thing), and if you come at it that way you will be disappointed. I’m not even personally overjoyed with the UI routing implementation. It isn’t my primary concern, and I keep hoping someone will use the ideas in it and contribute something better 😄 But anyway…my point is that to me Fulcro is about a pattern of data management, reasoning, and to some extent scalable code bases (though that is very much tied to the people doing it). I think people do get lost in the “extras” and fail to see those central bits clearly.

FWIW, I love “unscarifying”. I can't wait to see your talk!

Thank you, Gene! Glad to hear it works at least for somebody :)