The Future of JavaScript MVCs

Post by peterhunt » Fri, Dec 20, 2013, 9:31 PM UTC

jarpineh wrote: post #118

peterhunt wrote: post #99

Earlier quoted context omitted.

That's exactly what we encourage :) composition of higher level components that render down to other high level components that eventually render to (virtual) DOM.

I wonder if this approach would work with visual XML (Docbook) and HTML editing, where resulting DOM can be complex and large. Competent writer might generate loads of input (writing 100 letters per minute, copy-paste). If my writing tool has latencies, that annoys me far more than game latency. Other approach I have been testing is contenteditable, but this won't work with virtual DOM at all. Though how you parse an…

Post by peterhunt » Fri, Dec 20, 2013, 10:30 PM UTC

jarpineh wrote: post #142

peterhunt wrote: post #141

Earlier quoted context omitted.

We could do that probably. Would need your own parser With content editable we can just parse he html. We have an example in the repo.

> We could do that probably. Would need your own parser Parser for HTML and XML to generate React components and generate virtual DOM from that? This got me thinking. > With content editable we can just parse he html. We have an example in the repo. It must be the weekend denseness setting in... I grepped through React repo, but I just found bits in the core that had something to do with content editable. Could you p…

Post by jarpineh » Fri, Dec 20, 2013, 11:15 PM UTC

peterhunt wrote: post #143

jarpineh wrote: post #142

Earlier quoted context omitted.

> We could do that probably. Would need your own parser Parser for HTML and XML to generate React components and generate virtual DOM from that? This got me thinking. > With content editable we can just parse he html. We have an example in the repo. It must be the weekend denseness setting in... I grepped through React repo, but I just found bits in the core that had something to do with content editable. Could you p…

Check this out: https://github.com/facebook/react/pull/667

Post by rads » Sat, Dec 21, 2013, 8:00 AM UTC

jpatte wrote: post #131

lucian1900 wrote: post #126

Earlier quoted context omitted.

I don't see how language has anything to do with you criticism.

It's not really about a choice of language. My point is that if Om claims to be superior to other JS MVC frameworks - as it is presented as "the future of MVC frameworks" - it needs to be good (if not superior) in many aspects. Performance is a big deal all right, but another aspect (which seems essential to me) is that using this framework should be easy, concise and intuitive. And I've been kinda disappointed to se…

    (defn handle-new-todo-keydown [e {:keys [todos] :as app} owner]
    ...
            (om/update! app [:todos] conj
              {:id (guid) :title (.-value new-field)
               :created-at (js/Date.)  ;; 

    (defn todo-item [{:keys [id title editing completed] :as todo} {:keys [comm]}]
    ...
                ;; change this line
                (dom/label #js {:onDoubleClick #(handle-edit % todo m)} (str
    (:title todo) (:created-at todo)))
    ...)