4 ms·

This looks a bit like Angular 1.3 and 2.0 to me - DI, binding and repeats look like ng-model and ng-repeat.. I'm curious to see more when the full docs are out

This looks a bit like Angular 1.3 and 2.0 to me - DI, binding and repeats look like ng-model and ng-repeat.. I'm curious to see more when the full docs are out though. No mention of isomorphism or a virtual DOM, seems to be a bit behind the zeitgeist.

ZenoArrow 12y ago
I don't know why you missed it, but it mentions both isomorphism (code that can be run client side or server side) and the virtual DOM (web components, etc...).
- rabbyte 12y ago
  Correct me if I'm wrong but web components can use the native DOM without depending on a virtual DOM.
  - ZenoArrow 12y ago
    Not as far as I know. What I can tell you is that web component polyfills like Polymer end up partially recreating the shadow DOM, and that's a lot of work, unlikely to have been undertaken unless it was necessary.
- brentvatne 12y ago
  This is not mentioned in either the blog post or the docs, at least not easily findable with a cmd+f "Use some of the libraries on the server with NodeJS. i.e. DI." - some, and I'd expect an explicit mentioning of isomorphism if it were possible at the moment to render it on the server side. Shadow DOM != Virtual DOM. I mean the React-style Virtual DOM.
  - ZenoArrow 12y ago
    What are the main differences between the shadow DOM and the virtual DOM?
    - i_am_ralpht 12y ago
      Shadow DOM is a DOM structure that's hidden under a tag (for example, the <video> tag has a Shadow DOM which provides the controls and timecode UI). Virtual DOM is (typically) a pure JavaScript object-based DOM representation that gets somehow flushed to actual DOM (or to WebGL or anything else). You as the programmer use the Virtual DOM directly and try to avoid talking to the real DOM underneath. Virtual DOM has a few advantages, but the one that stands out in today's browsers is limiting DOM thrashing where you query the DOM (requiring an expensive recalc) and then modify the DOM (invalidating what was recalc'd) in a loop.
- bronson 12y ago
  I missed it too. Got a link or something? Or do you mean the hint that some of the code can run server-side? That seems obvious, and is not in itself isomorphism.
  - ZenoArrow 12y ago
    In that case, we need to establish what isomorphism is. What's your definition?
    - bronson 12y ago
      We probably agree on what "isomorphism" is, but maybe not "support"? If a platform claims to support isomorphism, I expect it to render server-side with zero drama/workarounds/blog posts. Support means that producing fully-rendered html is a core part of the product and documentation, not something glued on the side or pieces to reassemble on your own. From the wording, it looks like Aurelia isn't there yet?
Lazare 12y ago
Yeah. I just got done doing a very large SPA using Knockout, and I'm now starting a little side project with React/Flux. Pain points I found with the Knockout based app: Performance, stupidly messy data flows, hard to test, lack of isomorphism. My choice of React/Flux for my next project was based on that: React makes a big deal about performance (virtual DOM), sensible data flow (flux architecture, one-way data flows, events, etc.), testability, and isomorphism. I clicked on OPs link with some apprehension; is the stack I just chose already outdated? Not according to the blog post. They still need a "bunch of work" on performance and testing (which implies that it's not there yet, and also raises questions about priorities; testing seems like it should be more than an afterthought). There's no mention of isomorphism. And while technical details are sparse, it looks like there's no virtual DOM; no strongly enforced event model (like React has with Flux). Maybe it's there, but... ...given the amount of experience the author has writing JS frameworks, I'd have expected a lot more details on how this framework solves problems the programmer might have with other frameworks. I mean, the very first bullet is "Aurelia is written with vanilla ES6 and ES7 but transpiled and polyfilled to work on today’s Evergreen browsers. It may just be the most forward-thinking framework you've ever seen", but speaking just for myself, I've never ever thought to myself "man, this framework is awesome, but if only it had been written in ES7 and transpiled to work in my current browser!" I'm struggling to imagine why anyone would think that. Now, maybe it's just a bad blog post. I'll do some more digging. But the message I'm getting so far is "this framework was created to solve the kind of issues framework authors care about, not the issues developers using the framework care about". If true, it's not a good message. In short: Get off my lawn. :(
- digerata 12y ago
  I was quite surprised at how little support in browsers there was for es6 and 7. Essentially, every current and near future browser was developed against es5. http://kangax.github.io/compat-table/es6 http://kangax.github.io/compat-table/es6

ZenoArrow 12y ago

I don't know why you missed it, but it mentions both isomorphism (code that can be run client side or server side) and the virtual DOM (web components, etc...).

rabbyte 12y ago
Correct me if I'm wrong but web components can use the native DOM without depending on a virtual DOM.
- ZenoArrow 12y ago
  Not as far as I know. What I can tell you is that web component polyfills like Polymer end up partially recreating the shadow DOM, and that's a lot of work, unlikely to have been undertaken unless it was necessary.
brentvatne 12y ago
This is not mentioned in either the blog post or the docs, at least not easily findable with a cmd+f "Use some of the libraries on the server with NodeJS. i.e. DI." - some, and I'd expect an explicit mentioning of isomorphism if it were possible at the moment to render it on the server side. Shadow DOM != Virtual DOM. I mean the React-style Virtual DOM.
- ZenoArrow 12y ago
  What are the main differences between the shadow DOM and the virtual DOM?
  - i_am_ralpht 12y ago
    Shadow DOM is a DOM structure that's hidden under a tag (for example, the <video> tag has a Shadow DOM which provides the controls and timecode UI). Virtual DOM is (typically) a pure JavaScript object-based DOM representation that gets somehow flushed to actual DOM (or to WebGL or anything else). You as the programmer use the Virtual DOM directly and try to avoid talking to the real DOM underneath. Virtual DOM has a few advantages, but the one that stands out in today's browsers is limiting DOM thrashing where you query the DOM (requiring an expensive recalc) and then modify the DOM (invalidating what was recalc'd) in a loop.
bronson 12y ago
I missed it too. Got a link or something? Or do you mean the hint that some of the code can run server-side? That seems obvious, and is not in itself isomorphism.
- ZenoArrow 12y ago
  In that case, we need to establish what isomorphism is. What's your definition?
  - bronson 12y ago
    We probably agree on what "isomorphism" is, but maybe not "support"? If a platform claims to support isomorphism, I expect it to render server-side with zero drama/workarounds/blog posts. Support means that producing fully-rendered html is a core part of the product and documentation, not something glued on the side or pieces to reassemble on your own. From the wording, it looks like Aurelia isn't there yet?

Lazare 12y ago

Yeah. I just got done doing a very large SPA using Knockout, and I'm now starting a little side project with React/Flux. Pain points I found with the Knockout based app: Performance, stupidly messy data flows, hard to test, lack of isomorphism. My choice of React/Flux for my next project was based on that: React makes a big deal about performance (virtual DOM), sensible data flow (flux architecture, one-way data flows, events, etc.), testability, and isomorphism. I clicked on OPs link with some apprehension; is the stack I just chose already outdated? Not according to the blog post. They still need a "bunch of work" on performance and testing (which implies that it's not there yet, and also raises questions about priorities; testing seems like it should be more than an afterthought). There's no mention of isomorphism. And while technical details are sparse, it looks like there's no virtual DOM; no strongly enforced event model (like React has with Flux). Maybe it's there, but... ...given the amount of experience the author has writing JS frameworks, I'd have expected a lot more details on how this framework solves problems the programmer might have with other frameworks. I mean, the very first bullet is "Aurelia is written with vanilla ES6 and ES7 but transpiled and polyfilled to work on today’s Evergreen browsers. It may just be the most forward-thinking framework you've ever seen", but speaking just for myself, I've never ever thought to myself "man, this framework is awesome, but if only it had been written in ES7 and transpiled to work in my current browser!" I'm struggling to imagine why anyone would think that. Now, maybe it's just a bad blog post. I'll do some more digging. But the message I'm getting so far is "this framework was created to solve the kind of issues framework authors care about, not the issues developers using the framework care about". If true, it's not a good message. In short: Get off my lawn. :(

digerata 12y ago
I was quite surprised at how little support in browsers there was for es6 and 7. Essentially, every current and near future browser was developed against es5. http://kangax.github.io/compat-table/es6 http://kangax.github.io/compat-table/es6