4 ms·

I've got my problems with Rails: routing is overly complicated, the asset pipeline can be tricky, and so on. But Rails is very good at producing HTML and, in p

I've got my problems with Rails: routing is overly complicated, the asset pipeline can be tricky, and so on. But Rails is very good at producing HTML and, in particular, partial chunks of HTML. As the current thick-clients-in-javascript trend cools off (it's happening, this was at the top of /r/webdev yesterday: https://www.reddit.com/r/webdev/comments/4iphv4/12_year_of_progress/ https://www.reddit.com/r/webdev/comments/4iphv4/12_year_of_p...) people are going to migrate back to HTML as a transport for web apps, using libraries like http://intercoolerjs.org http://intercoolerjs.org. (Disclosure: I developed it) Rails is well positioned for that.

67726e 10y ago
What makes you think that being able to produce HTML is such an important piece, and that Raila delivers better than most other frameworks?
- carsongross 10y ago
  HTML gives you HATEOAS without thinking about it: http://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.html http://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.ht... and is the minimum level of complexity necessary for a human web interface. Rails isn't necessarily better than other platforms at producing HTML: it does support rendering partials which is nice: http://guides.rubyonrails.org/layouts_and_rendering.html http://guides.rubyonrails.org/layouts_and_rendering.html. So, rails is pretty good at it, but I can imagine other tools being perfectly competent at the problem as well.
  - dragonwriter 10y ago
    > HTML gives you HATEOAS without thinking about it No, it doesn't, though it certainly makes it simpler (than something not designed as a hypermedia format) to do HATEOAS if you think about it.
lmm 10y ago
Rails is still page-oriented, no? I've found Wicket is head and shoulders above anything else for actually producing HTML, and it can already do lightweight partial ajax updates to the UI if that's the style you're suggesting.
- carsongross 10y ago
  Rails lets you render partials directly. I've never used wicket, but it looks pretty good at this sort of thing.
conradfr 10y ago
> As the current thick-clients-in-javascript trend cools off I think that's wishful thinking. The drawing you link is great though.
- carsongross 10y ago
  Maybe. I've been through three JavaScript hype cycles now, though, so it isn't as unlikely as a lot of folks think.
dragonwriter 10y ago
> As the current thick-clients-in-javascript trend cools off ...thinks like WebAssembly will be ramping up, spurring a trend of thick-clients-in-other-than-JavaScript.
VeejayRampay 10y ago
The assets pipeline can be tricky, sure, but it's tackling an issue that is really hard to get right. Routing in Rails on the other hand, I don't really see what's so complicated about it. You define resources, you have namespaces, constraints, the DSL is extremely nice and straightforward, I think it's actually one of the huge successes of Rails as a framework.
- carsongross 10y ago
  IMO the asset pipeline is not worth the complexity. CDNs + caching do a good enough job of getting stuff to clients, so the complexity (and distinction between dev mode and production mode) isn't worth it. My problem with routing is that the default is an implicit semi-REST pattern, and that routing a lot of verbs to the same controller method is tedious. I prefer Sinatra's "ground up" model instead, although you can certainly write a rails router that way (and sinatra has the same verb problem.) But I concede that's a matter of taste.

67726e 10y ago

What makes you think that being able to produce HTML is such an important piece, and that Raila delivers better than most other frameworks?

carsongross 10y ago
HTML gives you HATEOAS without thinking about it: http://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.html http://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.ht... and is the minimum level of complexity necessary for a human web interface. Rails isn't necessarily better than other platforms at producing HTML: it does support rendering partials which is nice: http://guides.rubyonrails.org/layouts_and_rendering.html http://guides.rubyonrails.org/layouts_and_rendering.html. So, rails is pretty good at it, but I can imagine other tools being perfectly competent at the problem as well.
- dragonwriter 10y ago
  > HTML gives you HATEOAS without thinking about it No, it doesn't, though it certainly makes it simpler (than something not designed as a hypermedia format) to do HATEOAS if you think about it.

lmm 10y ago

Rails is still page-oriented, no? I've found Wicket is head and shoulders above anything else for actually producing HTML, and it can already do lightweight partial ajax updates to the UI if that's the style you're suggesting.

carsongross 10y ago
Rails lets you render partials directly. I've never used wicket, but it looks pretty good at this sort of thing.

conradfr 10y ago

> As the current thick-clients-in-javascript trend cools off I think that's wishful thinking. The drawing you link is great though.

carsongross 10y ago
Maybe. I've been through three JavaScript hype cycles now, though, so it isn't as unlikely as a lot of folks think.

dragonwriter 10y ago

> As the current thick-clients-in-javascript trend cools off ...thinks like WebAssembly will be ramping up, spurring a trend of thick-clients-in-other-than-JavaScript.

VeejayRampay 10y ago

The assets pipeline can be tricky, sure, but it's tackling an issue that is really hard to get right. Routing in Rails on the other hand, I don't really see what's so complicated about it. You define resources, you have namespaces, constraints, the DSL is extremely nice and straightforward, I think it's actually one of the huge successes of Rails as a framework.

carsongross 10y ago
IMO the asset pipeline is not worth the complexity. CDNs + caching do a good enough job of getting stuff to clients, so the complexity (and distinction between dev mode and production mode) isn't worth it. My problem with routing is that the default is an implicit semi-REST pattern, and that routing a lot of verbs to the same controller method is tedious. I prefer Sinatra's "ground up" model instead, although you can certainly write a rails router that way (and sinatra has the same verb problem.) But I concede that's a matter of taste.