3 ms·

> unnecessary for the vast majority of web applications There's a sliding scale of what counts as "necessary" to different developers. For example, the first e

by DougBTX 10y ago

> unnecessary for the vast majority of web applications There's a sliding scale of what counts as "necessary" to different developers. For example, the first entry in the intercooler.js examples is a "Click To Edit UI" that doesn't escape HTML in user input. For many websites, that probably doesn't matter all that much, but for developers that care about script injection, they might go for a different solution that makes that sort of problem harder to introduce. That exposes the underlying complexity though, since using string concatenation to generate HTML is no longer a safe option.

carsongross 10y ago
That's because I'm using a library, mockjax, to mock out AJAX requests for the examples, to keep them as simple as possible. Any sane server side web framework is going to escape HTML for you.
- DougBTX 10y ago
  I agree that it is good to keep the examples simple, I liked how easy it was to toggle between the live example and the source code. If the rendering was still done on the client using `userDisplayTemplate`, I'd guess that the response to the save web service call would be a JSON object. The server would then need to know that the user object it returns should have HTML strings as its properties, rather than just a plain text. Possible, but the complexity doesn't go away.
  - carsongross 10y ago
    I'm not sure what you are getting at. One of the core ideas with intercooler is to use HTML, not JSON, as your data transport, to get back to the original model of the web as described by Roy Fielding (REST/HATEOAS), rather than move more towards a JSON/RPC model. There are some good practical and theoretical reasons for doing this: http://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.html http://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.ht... http://intercoolerjs.org/2016/02/17/api-churn-vs-security.html http://intercoolerjs.org/2016/02/17/api-churn-vs-security.ht...
    - DougBTX 10y ago
      Ah, thanks, that makes much more sense. I hadn't noticed that was mock server-side code, I thought it was advocating "vanilla JS" as a client side framework, using string-bashing as a template language.

by DougBTX 10y ago

carsongross 10y ago

That's because I'm using a library, mockjax, to mock out AJAX requests for the examples, to keep them as simple as possible. Any sane server side web framework is going to escape HTML for you.

DougBTX 10y ago
I agree that it is good to keep the examples simple, I liked how easy it was to toggle between the live example and the source code. If the rendering was still done on the client using `userDisplayTemplate`, I'd guess that the response to the save web service call would be a JSON object. The server would then need to know that the user object it returns should have HTML strings as its properties, rather than just a plain text. Possible, but the complexity doesn't go away.
- carsongross 10y ago
  I'm not sure what you are getting at. One of the core ideas with intercooler is to use HTML, not JSON, as your data transport, to get back to the original model of the web as described by Roy Fielding (REST/HATEOAS), rather than move more towards a JSON/RPC model. There are some good practical and theoretical reasons for doing this: http://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.html http://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.ht... http://intercoolerjs.org/2016/02/17/api-churn-vs-security.html http://intercoolerjs.org/2016/02/17/api-churn-vs-security.ht...
  - DougBTX 10y ago
    Ah, thanks, that makes much more sense. I hadn't noticed that was mock server-side code, I thought it was advocating "vanilla JS" as a client side framework, using string-bashing as a template language.