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

71–80 of 159 posts

Re: The Future of JavaScript MVCs

#71

Post by swannodette »

jaredly wrote: post #50
DannoHung wrote: post #46

Earlier quoted context omitted.

Are there a lot of details to explain? An immutable data structure means that modifications to the structure tend to be memory cheap. So you save every instance you care about secure in the knowledge that it doesn't waste much space. Then to perform forward or backward operations, you just switch which version you're looking at.

maybe "details" is the wrong way to phrase it. I'm excited to see /a real world implementation/, either proving that it really is that simple, or showing what other complications arise.

I've already played around with some simple prototypes - it works as advertised. There'll be a future blog post showing how it can be done.

Re: The Future of JavaScript MVCs

#72

Post by swannodette »

jarpineh wrote: post #70

This is like a dream coming true. I don't like Javascript's quirks, nor programming DOM with templates nor functions. I'm looking to build somewhat complex UIs without having to think in JS and manage state. React absolves me from DOM and ClojureScript keeps JS at bay. Only if starting ClojureScript development wasn't so hard. I'd like to use browser REPL, IDE like LightTable. I am used to LiveReload's speed which ma…

The first build of ClojureScript app is somewhat slow because we need boot the JVM, compile ClojureScript, and then analyze and compile your code. After the first compile it should be sub second. I always use the auto build mode and when I'm developing I don't use any optimizations. Works well enough for me.

I'd start with this, http://swannodette.github.io/2013/10/27/the-essence-of-cloju...

Re: The Future of JavaScript MVCs

#73

Post by cia_plant »

possibilistic wrote: post #53
mtrimpe wrote: post #35

Earlier quoted context omitted.

Because there are millions of developers who can use the DOM and CSS to create their design and only a handful who can do the same with Canvas.

This argument is correct, but you can take it further: It's not so much about being able to do it with canvas. It's the fact that you have to reinvent all of your tools on top of canvas.

When you're tying your square wheels together into a big circle so they turn better, it's time to start reinventing.

Re: The Future of JavaScript MVCs

#74

Post by porker »

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?

Re: The Future of JavaScript MVCs

#75

Post by jarpineh »

swannodette wrote: post #72
jarpineh wrote: post #70

This is like a dream coming true. I don't like Javascript's quirks, nor programming DOM with templates nor functions. I'm looking to build somewhat complex UIs without having to think in JS and manage state. React absolves me from DOM and ClojureScript keeps JS at bay. Only if starting ClojureScript development wasn't so hard. I'd like to use browser REPL, IDE like LightTable. I am used to LiveReload's speed which ma…

The first build of ClojureScript app is somewhat slow because we need boot the JVM, compile ClojureScript, and then analyze and compile your code. After the first compile it should be sub second. I always use the auto build mode and when I'm developing I don't use any optimizations. Works well enough for me. I'd start with this, http://swannodette.github.io/2013/10/27/the-essence-of-cloju...

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 me. Unfortunately LT doesn't support that use case yet, and you can't use Chrome debugger inside it. I still need to see what the browser thinks is happening and not just the ClojureScript's side.

I did manage to get React + JSX, CoffeeScript and ClojureScript + bREPL working with LiveReload, in a single page app. That felt truly powerful.

Re: The Future of JavaScript MVCs

#76

Post by bretthopper »

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?

Going beyond the normal Undo to error/state correction. A lot of JS apps right now just ask a user to refresh the page when something goes wrong. This provides an easier way to get back into a previous working state.

Re: The Future of JavaScript MVCs

#77

Post by chongli »

cia_plant wrote: post #69
masklinn wrote: post #42

Earlier quoted context omitted.

> much less complicated for such applications. I'm uncertain that having to reimplement all your high-level drawing routines by hand and figuring out how to handle responsive and reimplementing all activation and behaviors on top of that is less complicated than just using what the DOM provides. Even text wrapping must be done by hand when you're using canvas.

I've written text wrapping and responsiveness code for canvas, in javascript - I don't think the complexity is even of the same order of magnitude as React or Angular.

What about line height? Judging by some of the responses I've seen on Stackoverflow, calculating this involves running a loop and querying the pixel colours from the canvas's buffer; a very ugly hack, if you ask me!

Re: The Future of JavaScript MVCs

#78

Post by programminggeek »

There was a really good talk from Charles Nutter about making JRuby fast and the mutable things that Ruby does that basically break caching and things that you do to make things faster at runtime.

I'm not surprised that persistent data structures can make things fast, in fact I've spent the last week speeding up a Rails app in some ugly spots by preloading the data structures to keep DB queries from happening, effectively turning a lot of just in time queries at the ORM level into a pre-loaded data graph. The speed is fantastic, but what is interesting is you could add a level of immutability to this and would be potentially even faster, especially on top of the JVM.

I've been playing with the idea of immutable entities in Obvious Architecture for a while and it really changes the way you look at your business logic and performance.

Re: The Future of JavaScript MVCs

#79

Post by d_j_s »

So I rewrote Backbone views to use a queue system that fires on requestAnimationFrame -https://github.com/danshearmur/backbone-fast-view

I'm getting pretty good results with swannodette's benchmarks - http://danshearmur.github.io/backbone-fast-view/

I'm getting approx 150ms in Chrome for benchmark 1 and about 400 ms for Chrome for benchmark 2

Re: The Future of JavaScript MVCs

#80

Post by cnp »

zaph0d wrote: post #63
jordwalke wrote: post #57

Jordan, from the React core developer team here. Awesome post, swannodette! This is exactly how we intended React to be used. As swannodette said, at Facebook, we use persistent data structures, in order to prune the update search space for comment updates. We've seen as much as a 10x improvement in update speed for certain operations. React is a really great fit for Om, persistent data structures, and functional pro…

Hi Jordan, ReactJS looks really awesome. Curious, what kind of persistent data-structures do you use at Facebook? Are they similar to the ones on Clojure[Script]?

I'm curious about this as well.
Post reply on HN