News for hackers. Stuff that matters.
Re:Server-side HTML vs. JS Widgets vs. Single-Page Web Apps by agentultra on Monday June 03, 2013 @07:28AM (#5812580)
I'm interested in single-page application frameworks... however as a developer whose built UI's for desktop applications I find the focus on the MVC design pattern rather strange. I've tried learning how to build these kinds of interfaces in Backbone and friends. However the learning curve is rather high and the metaphors don't make a lot of sense. I was surprised when, after bugging my JS developer friends, I finally got "Hello, world!" up on the screen.

As a test I was able to get a native cocoa application up on the screen in <30 lines of CL.

I realize it must have something to do with the whole document/DOM relationship that has perversed UI programming on the web this way... but it also doesn't seem like there's a way out. It's just not elegant so lets stop using that word.

Re:Server-side HTML vs. JS Widgets vs. Single-Page Web Apps by Joeri on Monday June 03, 2013 @12:32PM (#5814172)
You're right that the complexity derives from the DOM. But in my opinion the DOM isn't so much the problem as the fact that it is so hard to manipulate. There are two ways to manipulate it: by low-level node fiddling at a level far below that of the discrete UI elements being represented, or by deleting subtrees and replacing them from a serialized source (html), losing event handlers and embedded state in the process. Neither solution is usable when dealing with complex ui elements that have no corresponding html tag, so you end up needing an abstraction layer that implements of these mechanisms and does the boilerplate work to make it practical. Because of this abstraction layer things always get complicated as soon as you try to move beyond basic html tags with onclick handlers beause you end up learning the pseudo-dsl of the abstraction layer.

The long term solution is to make html itself extensible so you can define additional tags at the start of the page, with all the related logic, and then can go back to straight dom manipulation without needing any abstraction framework. This should become possible with web components and shadow dom, but we have a way to go still.