25 ms·

If you are willing to try Yet Another Javascript Library, I have been working on something that will make things a lot simpler: http://intercoolerjs.org http:/

If you are willing to try Yet Another Javascript Library, I have been working on something that will make things a lot simpler: http://intercoolerjs.org http://intercoolerjs.org Basically you annotate your HTML using plain old attributes, no javascript required, and your AJAX requests return HTML rather than JSON. It tries keep things very similar to more traditional web development, but leverages some of the HTTP features that normal HTML makes hard to get to (e.g. custom headers, non-GET/POST requests). One really nice advantage of this is you can use REST/HATEOAS as originally intended: http://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.html http://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.ht... If you are really sick of the javascript tool chains, it might be worth a look.

cyberferret 10y ago
+1 - I wish I had heard of Intercooler much earlier. I've just incorporated it into a couple of existing projects, and it really is the antz pantz when it comes to doing simple partial screen refreshes or background processes when buttons are clicked. Other than that, I've always had trouble getting my head around React. I recently discovered Vue.js [0] and built a small HN specific project in it [1], and to my (old) brain, it just seems more natural and intuitive for dynamic page templating. [0] - https://vuejs.org/ https://vuejs.org/ [1] - https://hackernoon.com/tophn-a-fun-side-project-built-with-vue-js-and-rethinkdb-f22159641c1b#.70e5lfrjk https://hackernoon.com/tophn-a-fun-side-project-built-with-v...
- Raed667 10y ago
  I might be a bit green but your setup doesn't seem "simple" at all for me!
shortstuffsushi 10y ago
Don't know that you'll want to hear this, but every time I've run into returning view data from the server, I've had problems (something something separation of concerns). Unless you have both a data endpoint directly and a separate view endpoint, or a data endpoint that you can dictate to return the view, I would not recommend this approach. You're blocking yourself into a corner doing it this way.
- carsongross 10y ago
  A JSON data API and an HTML (view) API are two different animals and should use different end points. REST/HATEOAS doesn't describe accurately or work well with JSON because it is not a hypertext. This is why newer JSON APIs are moving away from REST and towards things like GraphQL. REST/HATEOAS works great with HTML though, because HTML is a hypertext. You don't even have to think about it very hard, it just works. Read the above blog post, I explain this. People get hung up thinking I'm advocating adopting HTML for their public data API. I'm not. I'm advocating building your own web application in a restful manner against a separate set of HTTP end points and letting your data API satisfy the needs of your integration partners.
  - shortstuffsushi 10y ago
    Perhaps I'm missing the difference between your examples in HTML vs XML. Ultimately it's just another view of the same data, which could be driven all via the same request with a different Accept header. JSON, XML, and HTML would all provide identical data and the other requisite links, etc, HTML is just inherently human readable (ish, assuming browser rendering). I've had a couple of interesting projects developed much in that manner, where a single API served both a website (browser default Accept is HTML) and mobile requested with JSON Accept. A simple middleware layer that varies the response (which is just some plain old xxx object) and returns the preferred media. I'm not sure that I agree that with your analysis of JSON. Semantically you're correct about it not being hypertext, but I don't think that precludes it as an effective media for a REST/HATEOS application.
    - carsongross 10y ago
      That's the default in rails (view API and data API are the same controllers/shape using accepts headers). It's a mistake for anything beyond a basic data model, and maybe even for that. Read the blog linked above and the other articles linked from it, I explain the HATEOAS problem in more detail. JSON APIs are moving away from REST and towards a more RPC-style model, e.g. GraphQL. The industry is finally getting sick of shoe-horning JSON into a conceptual model that makes no sense for it. Anyway, intercooler is a different, simpler way to build web apps. If you are willing to split your data API out from your web app API, you can save a lot of complexity in your stack. We built a reasonably modern web app with it with no front end engineers, just a couple of gronky full stack guys with some rails experience, and not much more code than a normal rails app would require. We built our data API using Grape, rather than rails. Turned out very clean, decoupling the two. Yes, I am aware that I am telling you almost exactly the opposite of what almost everyone else does and that I appear insane.

cyberferret 10y ago

+1 - I wish I had heard of Intercooler much earlier. I've just incorporated it into a couple of existing projects, and it really is the antz pantz when it comes to doing simple partial screen refreshes or background processes when buttons are clicked. Other than that, I've always had trouble getting my head around React. I recently discovered Vue.js [0] and built a small HN specific project in it [1], and to my (old) brain, it just seems more natural and intuitive for dynamic page templating. [0] - https://vuejs.org/ https://vuejs.org/ [1] - https://hackernoon.com/tophn-a-fun-side-project-built-with-vue-js-and-rethinkdb-f22159641c1b#.70e5lfrjk https://hackernoon.com/tophn-a-fun-side-project-built-with-v...

Raed667 10y ago
I might be a bit green but your setup doesn't seem "simple" at all for me!

shortstuffsushi 10y ago

Don't know that you'll want to hear this, but every time I've run into returning view data from the server, I've had problems (something something separation of concerns). Unless you have both a data endpoint directly and a separate view endpoint, or a data endpoint that you can dictate to return the view, I would not recommend this approach. You're blocking yourself into a corner doing it this way.

carsongross 10y ago
A JSON data API and an HTML (view) API are two different animals and should use different end points. REST/HATEOAS doesn't describe accurately or work well with JSON because it is not a hypertext. This is why newer JSON APIs are moving away from REST and towards things like GraphQL. REST/HATEOAS works great with HTML though, because HTML is a hypertext. You don't even have to think about it very hard, it just works. Read the above blog post, I explain this. People get hung up thinking I'm advocating adopting HTML for their public data API. I'm not. I'm advocating building your own web application in a restful manner against a separate set of HTTP end points and letting your data API satisfy the needs of your integration partners.
- shortstuffsushi 10y ago
  Perhaps I'm missing the difference between your examples in HTML vs XML. Ultimately it's just another view of the same data, which could be driven all via the same request with a different Accept header. JSON, XML, and HTML would all provide identical data and the other requisite links, etc, HTML is just inherently human readable (ish, assuming browser rendering). I've had a couple of interesting projects developed much in that manner, where a single API served both a website (browser default Accept is HTML) and mobile requested with JSON Accept. A simple middleware layer that varies the response (which is just some plain old xxx object) and returns the preferred media. I'm not sure that I agree that with your analysis of JSON. Semantically you're correct about it not being hypertext, but I don't think that precludes it as an effective media for a REST/HATEOS application.
  - carsongross 10y ago
    That's the default in rails (view API and data API are the same controllers/shape using accepts headers). It's a mistake for anything beyond a basic data model, and maybe even for that. Read the blog linked above and the other articles linked from it, I explain the HATEOAS problem in more detail. JSON APIs are moving away from REST and towards a more RPC-style model, e.g. GraphQL. The industry is finally getting sick of shoe-horning JSON into a conceptual model that makes no sense for it. Anyway, intercooler is a different, simpler way to build web apps. If you are willing to split your data API out from your web app API, you can save a lot of complexity in your stack. We built a reasonably modern web app with it with no front end engineers, just a couple of gronky full stack guys with some rails experience, and not much more code than a normal rails app would require. We built our data API using Grape, rather than rails. Turned out very clean, decoupling the two. Yes, I am aware that I am telling you almost exactly the opposite of what almost everyone else does and that I appear insane.