3 ms·

What are you taking about? It's still javascript, javascript encapsulated in elements. You can view source code, make your own, and release it is custom elemen

• malandrew 12y ago
  <polymer-ajax url="http://gdata.youtube.com/feeds/api/videos/" params='{"alt":"json", "q":"chrome"}' handleAs="json" auto ></polymer-ajax> ... is not JavaScript. I see XML where there is one tag with 4 properties. Not a line of JavaScript there. Furthermore, it involves putting data in the DOM (e.g. the `params` property above), where getters and setters now need to go through the inefficient steps of serializing plain old javascript objects when setting a property and parsing a string as a JSON object when getting a JSON property. "Best thing happend in web in a long time IMHO." This is one of those times, when it's worth asking yourself the question "Hmmmm... putting everything in the DOM... What could possibly go wrong?" The simple fact that the DOM is the only thing that is not accessible to web workers should be a massive red flag. DOM is popular with noobs because it represents global state, which is easy to work on when you're starting out or working on small projects, but simply does not scale. This approach is effectively paving a cowpath that has a sign next to it that reads "hic sunt dracones".
  • malandrew 12y ago
    Furthermore, what is the impact here on memory usage when something fundamentally ephemeral like an AJAX request is declared in the DOM as a web component? If I instantiate a new XHR request in a function scope, the XHR request object gets allocated on the heap. I then typically bind callbacks to the events I care about within the same scope. Again, all are added to the heap because that's how mutable objects are allocated in JavaScript. That function scope eventually returns freeing the variable reference to that XHR object on the stack for that function scope. This XHR object will eventually be available to be garbage collected once all the bound events are fired and the callbacks execute and return. At this point the results have been passed on to their destination and no references should (ideally) remain pointing to the instantiated XHR object. The next time the GC sweeps, it can (theoretically) de-allocate the memory assigned for the XHR request and the memory for the event-bounded callbacks. With the approach above however, the XHR request is instantiated via a web component and a reference is held indefinitely until either the window is terminated/refreshed or the `polymer-ajax` element is removed from the DOM. I suspect that not only will the memory for the XHR object never be freed, but neither will the memory allocated to the anonymous or named functions bound to the events, since internally the XHR object may still hold a reference to these callbacks (unless the implementation of XHR in question specifically nullifies the reference to callbacks that will never be called again). We're basically now back at having developers unknowingly performing malloc() in a declarative XML-based syntax, and they are now required to perform free() manually via the removeChild() method on the parent DOM element if they want to get that memory back.