This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # admin-announcements (4)
- # beginners (21)
- # boot (37)
- # cider (41)
- # cljs-dev (3)
- # cljsjs (11)
- # cljsrn (4)
- # clojure (31)
- # clojure-austin (21)
- # clojure-belgium (30)
- # clojure-canada (1)
- # clojure-dusseldorf (2)
- # clojure-poland (7)
- # clojure-russia (20)
- # clojure-taiwan (1)
- # clojure-uk (45)
- # clojurescript (90)
- # core-async (8)
- # cursive (4)
- # data-science (1)
- # datomic (5)
- # dirac (6)
- # docker (1)
- # emacs (8)
- # hoplon (102)
- # ldnproclodo (2)
- # lein-figwheel (3)
- # leiningen (13)
- # off-topic (9)
- # om (54)
- # onyx (4)
- # other-languages (101)
- # pedestal (8)
- # planck (2)
- # protorepl (1)
- # re-frame (15)
- # reagent (13)
- # spacemacs (4)
- # untangled (126)
- # yada (4)
it would be nice to not have to clone a project to use untangled. typically just a dependency reference/version, plus some examples.
@fenton: I’m working on a more basic introduction that would walk through creating a very basic project, not anywhere close to done yet, but I’ll post in here when it is
https://clojurians.slack.com/archives/untangled/p1463077993001467 — still in the very early stages, no actual code yet, just concepts
i hope it begins by just adding a dependency to your project.clj or build.boot or something.
creating a new project.clj, adding the right dependencies, starting to build things out
I'd suggest you have another track...one that doesn't talk about the overview/architecture, but just gets right down to the (hopefully) few steps to get started.
maybe be careful not to duplicate the tutorial that is already there...since it seems okay...but the assumption it makes to clone a repo isn't the right starting point for people who want to use the stack.
that is what the tutorial does, u start by cloning a project...thats great for learning it...but when i want to use it in my own project...thats not the way to start...so there should be docs that focus on the using use case.
kind of. do you have an example of an intro that you like which illustrates the difference?
sure...all the clojure libraries out there begin with something like this; "Include: [abc/cool-lib "0.3.3"] in your dependencies"
we could have the simplest possible intro, but it would miss the whole reason untangled exists
no i dont think so...people dont want to read a whole bunch of stuff they maybe already know more or less just to give the framework a spin
we hear from the grapevine...untangled is cool give it a try....so we go to the web page, look for the dependency and then the simple examples to start using it.
@fenton: IMO that's is only possible when you are trying a library not a framework.
i realize you need more pieces...for this... you need a server etc... but you can have the 0-60 for the basic pieces... i.e. walk through building the todo app or something.
a framework has a bunch of opinionated decisions that your existing application probably does not conform to
k. i’ll add it to my backlog. the one I’m working on now is intended for a different audience
i’m not just doing it for the open source community, we have many developers at my company who are highly unfamiliar with the pieces of the stack
@currentoor: he was given the task of choosing what to use, that’s a question for him. I was hired after the decision was made, though from what I understand the reasoning was based primarily on the value of immutability for large scale enterprise software
i had a pretty tough time convincing my team to use full stack clojure(script) and we were traditionally a rails and ember shop
@fenton: i believe so, i've been coding in some variant of Lisp for a few years now
i was just curious, usually it's hard to make someone see the benefits of FP and Lisp without having them actually use it
@currentoor: sure... probably a personality thing. you make relationships with other devs and you talk with them... communicate the disadvantages, etc..., over time some come around...the ones that dont...well they are probably low-level devs anyway...so dont throw perls before swine so to speak.
I agree with what @fenton was suggesting. The example that I thought of was om.next itself. It is hard to get your head around, so rather than diving into todomvc with all of its parts, David Nolen just started out the very least that you needed, including creating the files. It helped me stay focused on the one idea that he was trying to get across, instead of getting distracted by trying to follow the flow of the program.
as it stands very few people will bother learning untangled if they cant use it. cloning a repo is not indicating the ability to use untangled.
So, there is work being done on a cookbook, the tutorial exists, and a lein template is partially done. Once the latter exists, we'll be adding docs of the form you're looking for (do X, then Y). I agree that most people want a 0-60 in 4.2 seconds...that is, unfortunately, not where we're at...and really, if that is all the patience you have you are not our target audience. If you like "easy" and evaluate a framework based on how easy it is (90% of engineers), then you're not going to like Untangled or Om.
So, from a marketing perspective, I'm not sure what the correct target is. Am I trying to win the Angular crowd. No. Reagent...maybe, if they've already experienced pain there.
So, Untangled isn't really in a popularity contest as I see it. It makes Om more approachable for enterprise programming. If you, as an engineer, (not an armchair programmer) are interested in truly evaluating relative merits of dev stacks, then 0-60 isn't what you care about....nor do I care to attract people that cannot think for themselves or read a manual....so, I guess those things stack together to make me think that the users I care to attract will currently overlook the lack of the 400 word tutorial, and will instead use the more extensive materials that are present...including full-stack working code, and interactive tutorial.
@tony.kay: fair enough...dont mean to knock the good work you have done....but I do disagree that a 0-60 thing doesn't have value. I'm here looking at untangled because I understand the merits already and want them, but we are all short of time and I also dont want to spend extra time reading about stuff I already understand... give me the 0-60 and assume I'm one of those people who have drunk the cool-aid. 🙂
each framework already has its inherent ramp up time.... look at all the time i wasted on angular! lol. Minimizing that is useful and a good criteria on how to judge a framework...do you have to learn a lot of anciliary stuff, or can you just go staight to the heart of the matter.
The second I put up a 0-60, I'll have 800 people in here asking me how to do X Y and Z
I'll make it "easy" when there is so much documentation and material available that these other users can handle it.
You are welcome to you opinion. You've head from the horses mouth where we're at. Take it or leave it....or Contribute what you think it should have.
i really dont intend to be... but i started with the untangle tutorial...i liked it, and wanted to use it...but didn't really see where/how to do that in a succint way so am now back at om.next... I'm being honest... just realating my experience.
If you find Om.next easier, then go for it...it is definitely more flexible. Lots more to write to get anything going...but plenty of people are productive with plenty of different things
The amount of material I myself have contributed to both projects should make it possible to build something in either. Both will require work.
I do agree with you on more docs, easier stuff....I want to do more video tutorials, walk-throughs, build things step-by-step...all that.
sure sure... i know you guys are doing a lot already... hopefully i can help out a bit.
itd be really helpful if the untangled server also printed out the stack trace for unknown exceptions: https://github.com/untangled-web/untangled-server/blob/master/src/untangled/server/impl/components/handler.clj#L73
i find myself adding debug statements myself to find the root cause at the moment, and its not fun 😕
@kenbier: agreed — the concern we have is from a security standpoint. we don’t want to send server stack traces back to the client, however we should show the full trace on the server