11–20 of 53 posts
Is it just me or does this seem like a "Fun" way to code up an unmaintainable mess? Some of the ideas such as the state synchronization stuff is neat, but would probably be better suited as part of another framework/template language.
Someone should take the underlying realtime datastore (http://github.com/marcuswestin/fin) and bundle it with mustache or !
I notice that you haven't technically OSSed it yet (not released under any license). Is this just an oversight?
Is it just me or does this seem like a "Fun" way to code up an unmaintainable mess? Some of the ideas such as the state synchronization stuff is neat, but would probably be better suited as part of another framework/template language.
Totally - remains to be seen! Someone should take the underlying realtime datastore ( http://github.com/marcuswestin/fin ) and bundle it with mustache or !
A video demonstrating it from this past March's Confoo web conference can be found here: http://www.youtube.com/phpframework#p/c/C102458C2FFD8ACF/7/8...
We're also planning to add a more direct syntax in the future so that you can easily set properties of objects directly to a changing data source without having to handle the assignment in a controlled callback, which we initially mandate due to taking the cautious route, thus allowing you to handle for data and security issues.
Disclaimer: I'm a co-founder of NOLOH
From a cursory reading, this isn't particularly new, even on the web. Essentially what he's done is implement bindings/key value observing, but with a new syntax instead of the one we already know (i.e., javascript). On the desktop Cocoa has done this very well, and on the web Cappuccino and SproutCore have copied the cocoa approach. There are also more lightweight libraries that provide binding support without a hea…
Reminds me bit of register globals. And generally blurring the line between clientside and serverside processing feels bit scary.
This certainly is an interesting idea. It seems to me though that all of your application logic is jammed into a single file at the presentation layer. This might suffice for very small apps, and that's fine if it is your goal. I can't imagine that you just define all of your logic in one file. How would you go about reusing code? Could you potentially separate out logic from your template? I would also like to see h…
Absolutely! You can declare something akin to a function, which takes arguments and emits HTML. Imagine e.g. let taskTemplate = template(task) { task.title } for (task in tasks) { taskTemplate(task) } I'm not decided on syntax yet. You can definitely separate out logic from template this way. Fun outputs javascript, not HTML - the javascript then builds the DOM.
From a cursory reading, this isn't particularly new, even on the web. Essentially what he's done is implement bindings/key value observing, but with a new syntax instead of the one we already know (i.e., javascript). On the desktop Cocoa has done this very well, and on the web Cappuccino and SproutCore have copied the cocoa approach. There are also more lightweight libraries that provide binding support without a hea…
The difference is the realtime synchronization across all clients. Fun comes with a complete network stack, ensuring that the state you're viewing is always up to date. Does that make sense? I actually do think that's a new value proposition.