I also personally like pedestal. However couple of reasons are holding me 
back - 

1) An easier integration with UI. All current frameworks such as Angular 
etc focus on easing the DOM manipulation. You define your model, and then 
define the relationship of your model with the DOM. The framework then 
takes care of it. 

Inversely pedestal focuses on easing the state management / event 
propagation for a web app. Yes this is a big concern on big single page 
apps. However most of the apps I work with, the former, DOM manipulation is 
the concern that dominates. 

Thus introduction of a nice widget system, which provides facilities for 
the former will go a long way to accelerate the adoption of pedestal.

2) Another problem is the cognitive load in developing a pedestal app. 
There are too many settings, multiple ways to do the same things, concepts 
that seem to overlap, lack of simple easy to grasp recipe type examples. 

I would like to have an easy way to start and develop with pedestal. There 
is too much to learn before you write your first line of code, and I dont 
even think I can ask a new developer to just go and learn pedestal on his 
own. So please bring down the barrier. 

Hope to use pedestal on my projects soon. And a big thanks to the pedestal 
team for this amazing piece of code. 

Thanks,
Murtaza


On Tuesday, November 12, 2013 10:44:38 AM UTC+5:30, Mars0i wrote:
>
> Thanks, Cedric, for insightful comments about documentation.
>
> I'll add that for me, if the only documentation is a video, I have to 
> *really* want to learn about a programming tool to go any further.  Videos 
> don't allow you to take in information any faster than  information at 
> exactly the speed at which the video presents it.  Reading lets you go 
> faster, or slower, or visually decide what to skip, or find passages by 
> their content.  Even without hyperlinks.  (Yes, when motion matters, video 
> is nice.)
>
> On Monday, November 11, 2013 12:04:09 AM UTC-6, Cedric Greevey wrote:
>>
>> IMO it can often be a lack of readable, searchable, nice-to-navigate 
>> text/hypertext that can be a barrier to entry. In fact all of these are 
>> unfortunately common in various parts of the geekosphere:
>>
>> 1. Projects whose *only* documentation (or the only version of certain 
>> key information) is in videos. Not searchable. Not easy to navigate to a 
>> particular part (need to remember roughly when it is, or rewatch half the 
>> thing). Expensive for mobile users with capped or per-megabyte data plans.
>>
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to