3 ms·

What a strange strange choice. Instead of moving responsibilities to a imperfect but very flexible turing-complete language (javascript), they are trying to sho

What a strange strange choice. Instead of moving responsibilities to a imperfect but very flexible turing-complete language (javascript), they are trying to shoehorn everything into a markup language originally designed as an abstraction for documents (html). I liked a lot of what I saw in the project, but this "ajax as an element" makes me want to facepalm, or at least scratch my head and wonder "why?!?" Can someone from the polymer team elaborate the reasoning behind this?

andybak 12y ago
I'm sure I want to defend this particular implementation without looking at it more but 'declarative' is quite a nice programming style as long as you can easily override it with 'proper' code when you hit it's limits - see Django's models, forms, admin etc.
- malandrew 12y ago
  Totally agree with declarative code that can be overridden with "proper" code. However in this particular instance, the declarative API in HTML for getting a resource at a particular URI already exists in the form of the "href" property. I don't understand what AJAX here adds at all, since it's not congruous with the semantics of the term AJAX -> "Asynchronous Javascript and XML". There is no javascript there. There's no notion of "asynchronicity" in a declarative interface since async connotes flow control. And the XML (part) used to refer to the original data structure format that was retrieved, whereas most people these days use JSON and even this example uses JSON. It's not even clear from this example, what is done with the JSON data fetched here. It's not assigned to a variable or returned by a callback. The script below the element in fact uses globals to access the code, since that is basically what `document.querySelector` does. Putting stuff in the DOM is the equivalent of saving all your variables on the window object and then accessing them with `window.myDomElement`, but in a more verbose, indirect and non-performant way. var ajax = document.querySelector('polymer-ajax'); ajax.addEventListener("polymer-response", function(event) { assert.isTrue(event.detail.response.feed.entry.length > 0); done(); }); Furthermore, I noticed in some of the markup elements, the addition of a "url" property. How does "url" differ from "href", especially, when all the examples I saw had URIs pointing to *.html hypertext documents. Is "url" a new property that exists in a standard somewhere? If not, I was under the impression that non-standard HTML properties are supposed to be prefixed.
rnnr 12y ago
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 elements. Best thing happend in web in a long time IMHO.
- 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.

andybak 12y ago

I'm sure I want to defend this particular implementation without looking at it more but 'declarative' is quite a nice programming style as long as you can easily override it with 'proper' code when you hit it's limits - see Django's models, forms, admin etc.

malandrew 12y ago
Totally agree with declarative code that can be overridden with "proper" code. However in this particular instance, the declarative API in HTML for getting a resource at a particular URI already exists in the form of the "href" property. I don't understand what AJAX here adds at all, since it's not congruous with the semantics of the term AJAX -> "Asynchronous Javascript and XML". There is no javascript there. There's no notion of "asynchronicity" in a declarative interface since async connotes flow control. And the XML (part) used to refer to the original data structure format that was retrieved, whereas most people these days use JSON and even this example uses JSON. It's not even clear from this example, what is done with the JSON data fetched here. It's not assigned to a variable or returned by a callback. The script below the element in fact uses globals to access the code, since that is basically what `document.querySelector` does. Putting stuff in the DOM is the equivalent of saving all your variables on the window object and then accessing them with `window.myDomElement`, but in a more verbose, indirect and non-performant way. var ajax = document.querySelector('polymer-ajax'); ajax.addEventListener("polymer-response", function(event) { assert.isTrue(event.detail.response.feed.entry.length > 0); done(); }); Furthermore, I noticed in some of the markup elements, the addition of a "url" property. How does "url" differ from "href", especially, when all the examples I saw had URIs pointing to *.html hypertext documents. Is "url" a new property that exists in a standard somewhere? If not, I was under the impression that non-standard HTML properties are supposed to be prefixed.

rnnr 12y ago

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 elements. Best thing happend in web in a long time IMHO.

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.