6 ms·

In Polymer ajax is an element: https://github.com/PolymerLabs/polymer-ajax/blob/master/test/html/polymer-ajax.html https://github.com/PolymerLabs/polymer-ajax/b

by lebek 12y ago

In Polymer ajax is an element: https://github.com/PolymerLabs/polymer-ajax/blob/master/test/html/polymer-ajax.html https://github.com/PolymerLabs/polymer-ajax/blob/master/test...

malandrew 12y ago
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.
tkps 12y ago
Correction to OP: In Polymer, ajax CAN be an element. Or not. You can build whatever elements you want in Polymer (even non-visual utility elements like xhr and localStorage), but it's YOUR job (the developer) to choose the elements that fit in with the goals and architecture of your project. Equating the fact that Polymer PROVIDES a declarative ajax element with the inevitability that any project you build will be fraught with bad code factoring and memory bloat because you MUST use it is like saying that because jQuery UI provides a Tab View, all of your jQuery UI's will be horrible because you must build them only out of Tab Views. Polymer just provides the sugar for minting your own custom elements, as well as a solid reference set of pre-built elements (core-, paper-); which ones you choose to use is up to you. Most of this discussion largely misses the point and elegance of what Web Components generally and Polymer specifically are gunning for: The ability to create, reuse, and share well-factored, arbitrary pieces of web functionality (which may or may not include presentation) that have a well-defined imperative API (instance properties, methods) as well as a familiar, serializable declarative syntax (HTML) that can be manipulated imperatively after the fact (DOM), that will (one day, fingers crossed) be consumed natively by all browsers, without today's existing framework-based silos (React components, Angular directives, etc.). When it makes sense in your application (i.e., when you determine you get more use out of factoring it as a reusable element), then promote that functionality to an element; otherwise, you're free to embed that functionality (including ajax requests) as imperative JavaScript inside the component using the techniques you use today. As for why you might be interested in a declarative <ajax> element: Polymer also provides declarative property binding and templating, which makes this possible (and absurdly simple, and very cool IMO): <select value="{{department}}"> <option value="eng" selected>Engineering</option> <option value="sales">Sales</option> <option value="hr">Human Resources</option> </select> <core-ajax url="/{{department}}.json" handleAs="json" response="{{employees}}" auto></core-ajax> <template repeat="{{employee in employees}}"> <div>{{employee.name}}</div> <img src="{{employee.avatar}}"> </template> Note from the above example: - Completely declarative (no imperative JS required) - No boilerplate querySelectors required - No boilerplate addEventListeners required - Good points for readability and understanding author intent - Are there times where you may need to dynamically create and throw away XHR's based on complex heuristics that don't readily fit into a declarative model like above, or when the maintainability benefits of doing so don't justify whatever (hopefully small) cost there is to instantiating an element and holding it in the DOM while the view is in use vs. using the xhr API imperatively? (rhetorical question: survey says...?) - In those cases, Polymer doesn't force it's opinion on you that in a lot of cases declarative elements can be good. In those cases, make your xhr calls imperatively like you do today, and apply the component model in the vast majority of other cases where it does make sense. Time will tell how developers apply this new component model, and Polymer is doing a lot of experimentation in the open to try and push those boundaries and see what sticks.

by lebek 12y ago

In Polymer ajax is an element: https://github.com/PolymerLabs/polymer-ajax/blob/master/test/html/polymer-ajax.html https://github.com/PolymerLabs/polymer-ajax/blob/master/test...

malandrew 12y ago

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.

tkps 12y ago

Correction to OP: In Polymer, ajax CAN be an element. Or not. You can build whatever elements you want in Polymer (even non-visual utility elements like xhr and localStorage), but it's YOUR job (the developer) to choose the elements that fit in with the goals and architecture of your project. Equating the fact that Polymer PROVIDES a declarative ajax element with the inevitability that any project you build will be fraught with bad code factoring and memory bloat because you MUST use it is like saying that because jQuery UI provides a Tab View, all of your jQuery UI's will be horrible because you must build them only out of Tab Views. Polymer just provides the sugar for minting your own custom elements, as well as a solid reference set of pre-built elements (core-, paper-); which ones you choose to use is up to you. Most of this discussion largely misses the point and elegance of what Web Components generally and Polymer specifically are gunning for: The ability to create, reuse, and share well-factored, arbitrary pieces of web functionality (which may or may not include presentation) that have a well-defined imperative API (instance properties, methods) as well as a familiar, serializable declarative syntax (HTML) that can be manipulated imperatively after the fact (DOM), that will (one day, fingers crossed) be consumed natively by all browsers, without today's existing framework-based silos (React components, Angular directives, etc.). When it makes sense in your application (i.e., when you determine you get more use out of factoring it as a reusable element), then promote that functionality to an element; otherwise, you're free to embed that functionality (including ajax requests) as imperative JavaScript inside the component using the techniques you use today. As for why you might be interested in a declarative <ajax> element: Polymer also provides declarative property binding and templating, which makes this possible (and absurdly simple, and very cool IMO): <select value="{{department}}"> <option value="eng" selected>Engineering</option> <option value="sales">Sales</option> <option value="hr">Human Resources</option> </select> <core-ajax url="/{{department}}.json" handleAs="json" response="{{employees}}" auto></core-ajax> <template repeat="{{employee in employees}}"> <div>{{employee.name}}</div> <img src="{{employee.avatar}}"> </template> Note from the above example: - Completely declarative (no imperative JS required) - No boilerplate querySelectors required - No boilerplate addEventListeners required - Good points for readability and understanding author intent - Are there times where you may need to dynamically create and throw away XHR's based on complex heuristics that don't readily fit into a declarative model like above, or when the maintainability benefits of doing so don't justify whatever (hopefully small) cost there is to instantiating an element and holding it in the DOM while the view is in use vs. using the xhr API imperatively? (rhetorical question: survey says...?) - In those cases, Polymer doesn't force it's opinion on you that in a lot of cases declarative elements can be good. In those cases, make your xhr calls imperatively like you do today, and apply the component model in the vast majority of other cases where it does make sense. Time will tell how developers apply this new component model, and Polymer is doing a lot of experimentation in the open to try and push those boundaries and see what sticks.