Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Future of JavaScript MVCs

swannodette.github.io

Post reply on HN
Print view View original

111–120 of 159 posts

Re: The Future of JavaScript MVCs

#111

Post by dgreensp »

I've been watching Clojure for a while, and I love the spirit of this work.

However, as a framework author, I feel obliged to point out that of course you can create a more expressive and performant UI framework in a language with S-expressions, macros, and value semantics. What's hard is doing it in JavaScript. :)

It also feels a bit like reverse logic to cite ever-faster JavaScript VMs as a reason to choose a new framework for performance reasons -- shouldn't it matter less exactly how you structure your application logic when you're running on a "fusion reactor"? -- but I realize there's some subtlety here about lower constants enabling better algorithms. (Still, if your framework includes a language compiler or gets to take advantage of an expressive macro system, it should be able to run on anything.)

Once it's possible to compile ClojureScript without booting up a JVM -- which could happen if it becomes self-hosting -- I'll make a Meteor package for it. I'd also like to see the compile times get a little shorter and the runtime library get a little smaller.

Re: The Future of JavaScript MVCs

#112

Post by ludwigvan »

_sh wrote: post #88
swannodette wrote: post #2

I apologize that the Om TodoMVC version is a little bit buggy at the moment, I put it together mostly to demonstrate the benefits of the React/Om model and it appears I missed a couple of TodoMVC behavior issues as they weren't important for demonstrating the approach - I'll try to clean up these annoyances later this evening. Feel free to ask any questions.

Thanks for posting this. Forgive me for not looking over your code before asking: how does Om compare with Pedestal? Am I correct in thinking there is a lot of architecture overlap, with Pedestal's application state map occupying a similar role to React's virtual DOM, and mutation through message tuples in channels? Both frameworks seem to offer similar advantages: decoupled model and view, UI state playback (VCR sty…

Yes, you are right, there are overlaps. Pedestal is undergoing a major rewrite these days, as I heard from the team at the ClojureConj. Also, Brenton Ashworth, Pedestal's developer has recently started investigating reactjs and found that it "perfectly complements the new version of Pedestal" (see his Twitter https://twitter.com/brentonashworth ) so exciting things to come!

Re: The Future of JavaScript MVCs

#114

Post by ludwigvan »

porker wrote: post #74
bretthopper wrote: post #5

There's two big highlights for me: > Thus we don't need React operations like setState which exists to support both efficient subtree updating as well as good Object Oriented style. Subtree updating for Om starting from root is always lightning fast because we're just doing reference equality checks all the way down. I don't think anyone actually likes using explicit setters/getters in frameworks like Backbone and Em…

>> VCR playback of UI state > I can't wait for details on this. This has gotten me really excited about client-side apps again. Why? I'm curious what I'm missing about it and the possibilities you see?

A bit vague, but this might come in handy in taking screenshots of various states, and using in some sort of visual diffing.

Re: The Future of JavaScript MVCs

#115

Post by danneu »

_pmf_ wrote: post #106

On another note: maybe if the installation of ClojureScript would be manageable in, say, an hours instead of having to search half a day among outdated information, more people would try it (and this is from someone who already uses Clojure and Leiningen a bit). Clojure and its libraries has the worst documentation, and this malpractice seems to be continued in ClojureScript.

https://github.com/magomimmo/modern-cljs is how I got started with Cljs. If you scroll down, you'll see some tutorials that get you set up and lead you to a workflow.

http://swannodette.github.io/2013/10/27/the-essence-of-cloju...

Re: The Future of JavaScript MVCs

#116

Post by jarpineh »

adrianm wrote: post #86
jarpineh wrote: post #75

Earlier quoted context omitted.

Thank you, yours is what I tried first and it's definitely fastest, sub second after first compile. However there is no REPL like cljs-start and couple of others I tested have. Between cljsbuild, Austin and LightTable I haven't yet found a stable and fast solution yet. I'll try adding these various REPLS to your example and see what happens. External browser with REPL inside LightTable seems easiest for a noob like m…

I hear your pain - I can't live without a REPL, and a stable browser REPL for ClojureScript development is a must. I personally use Emacs and Austin to hook the browser REPL into nrepl. Here are some sample files that you can take a look at. Here's a sample project.clj: https://github.com/aamedina/foundation/blob/feature/cljs/pro... I've become a fan of Stuart Sierra's Reloaded workflow: http://thinkrelevance.com/blo…

Thank you. I will definitely take a look at these over the weekend. User.clj seems particularly useful. Reloaded workflow reminds me of IPython, where you need to reload modules and reset the object instances for the new code to take effect.

Re: The Future of JavaScript MVCs

#117

Post by jarpineh »

jamii wrote: post #94
jarpineh wrote: post #75

Earlier quoted context omitted.

Thank you, yours is what I tried first and it's definitely fastest, sub second after first compile. However there is no REPL like cljs-start and couple of others I tested have. Between cljsbuild, Austin and LightTable I haven't yet found a stable and fast solution yet. I'll try adding these various REPLS to your example and see what happens. External browser with REPL inside LightTable seems easiest for a noob like m…

> External browser with REPL inside LightTable seems easiest for a noob like me. Unfortunately LT doesn't support that use case yet... It certainly does :) On the connections panel click 'Add connection' and then 'Browser (External)' The first time you do that it will give you a script tag to add to your page. Once you've added that and loaded the page in the browser, try again and it will connect. You can email me (…

Ah, I see. Thanks for the pointer. The docs on connections pane list only JavaScript, CSS and HTML can be evaluated, so I did not try with ClojureScript. I however did try to connect from LT to nREPL which had a running bREPL to external browser. That did not work (no connection), though I have no idea if it even should... ;)

I'll see how it goes and will post to the LT group if I stumble on something.

Re: The Future of JavaScript MVCs

#118

Post by jarpineh »

peterhunt wrote: post #99
gfodor wrote: post #97

This is really cool, and I am one of those people who rolls their eyes whenever there is another article about some newfangled way to build Javascript apps on HN. One logical step from here is instead of having a one-to-one correspondence between the "virtual" DOM and the browser DOM is to introduce a higher level meta representation based upon the context. This seems like a logical path towards a generative, project…

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 existing XML document to React's virtual DOM is beyond me. Perhaps you have to generate function calls SAX style.

Re: The Future of JavaScript MVCs

#119

Post by Joeri »

sebmarkbage wrote: post #49
EGreg wrote: post #23

How is this different from the dirty checking that Angular does in its ModelView update cycle?

React does the diffing on the output (which is a known serializable format, DOM attributes). This means that the source data can be of any format. It can be immutable data structures and state inside of closures. The Angular model doesn't preserve referential transparency and therefore is inherently mutable. You mutate the existing model to track changes. What if your data source is immutable data or a new data struc…

So, maybe i'm misunderstanding, but, the perf advantage is that react waits until the next RAF and then only updates the parts of the DOM that actually changed? So, now i'm wondering: why can't the browser do that? Isn't this whole middle-man approach something to eventually be optimized out?

Re: The Future of JavaScript MVCs

#120

Post by ThomasDeutsch »

ibdknox wrote: post #13

We've been thinking about this a lot lately for some of the projects we've been doing for Light Table and we've essentially been doing the same thing as what David's proposing here. What react ultimately opens up is a way to do immediate mode UI [1] on top of the DOM _efficiently_, which changes things pretty dramatically. It means we can start to treat the browser as just a renderer and get the infectious design dec…

I thought that "Aurora" would be something like OM :)
Post reply on HN