5 ms·

I'm all for new frameworks that emphasize different ideas and philosophies. If nobody ever tried experimenting with a new approach, we wouldn't have Rails in th

I'm all for new frameworks that emphasize different ideas and philosophies. If nobody ever tried experimenting with a new approach, we wouldn't have Rails in the first place. So kudos to Luca and his fine work in developing Lotus. I like much of what I see. That being said, I feel like YARWF (Yet Another Ruby Web Framework) is not the most pressing matter in the web space today, and I take exception to the notion that this is a complete web framework. It's not. A complete web framework has client-side components that facilitate two-way communication to/from the server, data binding, HTML5 history state-based page/view swapping, etc. In other words, the type of stuff being addressed by Angular, etc. At this point I wouldn't even characterize Rails itself as a "complete web framework"...it's proven itself to be incomplete and needs something more to be added to it for this kind of stuff. What's the solution? Well, most people in the Ruby world do the typical route of a Ruby + Rails/whatever backend and a JS-based (or CoffeeScript-based) frontend. But I don't like it. I want one language that works on both sides and in fact allows OOP code sharing between the two. That's why I'm so bullish on Opal (http://opalrb.org http://opalrb.org) -- Ruby-to-JS compiler. It may not be perfect, but it's usable and it's here now. What we need is a framework built on top of Opal that is to the client what Rails, or Lotus, is to the server. Then I think we can safely say that we have a complete web framework solution for Ruby. Until then...not quite.

diegosouza 12y ago
You say "A complete web framework has client-side components", but you don't consider there are action based frameworks and component based frameworks. They follow different approaches. Lotus is action based.
bliker 12y ago
You are forgetting that not all people are building thick-client applications.
gnufied 12y ago
> I want one language that works on both sides and in fact allows OOP code sharing between the two. I think, having one language in both frontend and backend does not work in long run, regardless of your preferred language of choice. we love ruby and yet where I work - we actively maintain Ruby, Python, Javascript and Java applications. Besides, I find it too hard to write OOP code which is reusable within same problem domain, writing OOP code that crosses the concerns between backend and frontend sounds like inviting lot of problems and lot of useless discussion on - which code goes where. EDIT: I didn't mean business agnostic code can't be shared between frontend and backend btw. Date parsing, uri parsing etc are examples of such libraries. But overall aiming to write business code that can be shared between frontend and backend is problematic.
- zem 12y ago
  there are some great frameworks that do do one language everywhere (my top choices would be om and hoplon from the clojurescript camp, and opa from the custom language camp). there is something to be said for being able to seamlessly pass data around between the frontend and backend, and letting the language and framework handle the low-level details for you.
  - deleted 12y ago
    [deleted]
  - sbov 12y ago
    I've always thought this would be nice, but whenever I actually design the theoretical code that would use this, the savings is much less than I would have thought. Real world actualities like security and privacy can either remove many of your gains or, if you ignore them, leave you with what I'd consider a buggy website.
- alttab 12y ago
  This can happen with knockout and other libraries when you end up dumping data into an object to send over simply to render it view side. You end up with a lot of wires between your controller and the view template rendered on the client side.
thecoffman 12y ago
>A complete web framework has client-side components that facilitate two-way communication to/from the server, data binding, HTML5 history state-based page/view swapping, etc. In other words, the type of stuff being addressed by Angular, etc. No. I can't possibly disagree with this any more strongly. I'm probably on the wrong side of history here, but Javascript absolutely should _not_ be a requirement for using a website. If your website doesn't work with NoScript turned on, I won't utilize it. Full stop. In my mind Javascript should be used for progressive enhancement for those users that opt to enable it (or I suppose more correctly: choose not to disable it). Building a thick client web app is the fastest route to ensuring I won't use it.
- blktiger 12y ago
  You are welcome to hold that opinion. Just keep in mind that the majority of users don't even know what javascript is or how to disable it. Depending on the audience, the fact that you don't want to enable javascript may or may not be a concern to the developers.
- Igglyboo 12y ago
  >If your website doesn't work with NoScript turned on, I won't utilize it. You're definitely in the minority then, most users don't even know what javascript is let alone NoScript. I find it ridiculous that people are arguing against javascript, we're using a computer and not allowing it to run code.
  - mercer 12y ago
    I was, and am, mostly on the side that argues that client-side javascript support can be assumed to such a degree that it can safely be considered requirement in a lot of cases. However, I do have some reservations of a more 'ideological' nature when it comes to requiring javascript when it isn't strictly necessary. I still believe one of the most powerful things about the web is the (relative) simplicity of the request/response server-side-rendering approach. There are so many ways in which a web page can be consumed (scraped, read-later-tools, etc.), within 'fair' boundaries of course. And this often falls apart because of client-side javascript. This is fine when it concerns a web-app that is specifically made for browsers (where ideally there's also a public-facing API). But for most other things it should not be necessary, and I believe it harms the possibilities of the open web. And quite often I find that it deceases the usability in general (back-button breakage, etc.). Of course, my ideal solution is both server- and client-side support, used appropriately, through something like React or PhantomJS.
Skoofoo 12y ago
Vienna is a Ruby web front-end framework that looks promising. https://github.com/opal/vienna https://github.com/opal/vienna
Iftheshoefits 12y ago
> A complete web framework has client-side components that facilitate two-way communication to/from the server, data binding, HTML5 history state-based page/view swapping, etc. In other words, the type of stuff being addressed by Angular, etc. < What you describe sounds very much like Plato's shadows (search for "Allegory of the Cave") when compared to a native application. Web browsers aren't operating systems. They weren't and still aren't designed to be general application execution environments.

diegosouza 12y ago

You say "A complete web framework has client-side components", but you don't consider there are action based frameworks and component based frameworks. They follow different approaches. Lotus is action based.

bliker 12y ago

You are forgetting that not all people are building thick-client applications.

gnufied 12y ago

> I want one language that works on both sides and in fact allows OOP code sharing between the two. I think, having one language in both frontend and backend does not work in long run, regardless of your preferred language of choice. we love ruby and yet where I work - we actively maintain Ruby, Python, Javascript and Java applications. Besides, I find it too hard to write OOP code which is reusable within same problem domain, writing OOP code that crosses the concerns between backend and frontend sounds like inviting lot of problems and lot of useless discussion on - which code goes where. EDIT: I didn't mean business agnostic code can't be shared between frontend and backend btw. Date parsing, uri parsing etc are examples of such libraries. But overall aiming to write business code that can be shared between frontend and backend is problematic.

zem 12y ago
there are some great frameworks that do do one language everywhere (my top choices would be om and hoplon from the clojurescript camp, and opa from the custom language camp). there is something to be said for being able to seamlessly pass data around between the frontend and backend, and letting the language and framework handle the low-level details for you.
- deleted 12y ago
  [deleted]
- sbov 12y ago
  I've always thought this would be nice, but whenever I actually design the theoretical code that would use this, the savings is much less than I would have thought. Real world actualities like security and privacy can either remove many of your gains or, if you ignore them, leave you with what I'd consider a buggy website.
alttab 12y ago
This can happen with knockout and other libraries when you end up dumping data into an object to send over simply to render it view side. You end up with a lot of wires between your controller and the view template rendered on the client side.

thecoffman 12y ago

>A complete web framework has client-side components that facilitate two-way communication to/from the server, data binding, HTML5 history state-based page/view swapping, etc. In other words, the type of stuff being addressed by Angular, etc. No. I can't possibly disagree with this any more strongly. I'm probably on the wrong side of history here, but Javascript absolutely should _not_ be a requirement for using a website. If your website doesn't work with NoScript turned on, I won't utilize it. Full stop. In my mind Javascript should be used for progressive enhancement for those users that opt to enable it (or I suppose more correctly: choose not to disable it). Building a thick client web app is the fastest route to ensuring I won't use it.

blktiger 12y ago
You are welcome to hold that opinion. Just keep in mind that the majority of users don't even know what javascript is or how to disable it. Depending on the audience, the fact that you don't want to enable javascript may or may not be a concern to the developers.
Igglyboo 12y ago
>If your website doesn't work with NoScript turned on, I won't utilize it. You're definitely in the minority then, most users don't even know what javascript is let alone NoScript. I find it ridiculous that people are arguing against javascript, we're using a computer and not allowing it to run code.
- mercer 12y ago
  I was, and am, mostly on the side that argues that client-side javascript support can be assumed to such a degree that it can safely be considered requirement in a lot of cases. However, I do have some reservations of a more 'ideological' nature when it comes to requiring javascript when it isn't strictly necessary. I still believe one of the most powerful things about the web is the (relative) simplicity of the request/response server-side-rendering approach. There are so many ways in which a web page can be consumed (scraped, read-later-tools, etc.), within 'fair' boundaries of course. And this often falls apart because of client-side javascript. This is fine when it concerns a web-app that is specifically made for browsers (where ideally there's also a public-facing API). But for most other things it should not be necessary, and I believe it harms the possibilities of the open web. And quite often I find that it deceases the usability in general (back-button breakage, etc.). Of course, my ideal solution is both server- and client-side support, used appropriately, through something like React or PhantomJS.

Skoofoo 12y ago

Vienna is a Ruby web front-end framework that looks promising. https://github.com/opal/vienna https://github.com/opal/vienna

Iftheshoefits 12y ago

> A complete web framework has client-side components that facilitate two-way communication to/from the server, data binding, HTML5 history state-based page/view swapping, etc. In other words, the type of stuff being addressed by Angular, etc. < What you describe sounds very much like Plato's shadows (search for "Allegory of the Cave") when compared to a native application. Web browsers aren't operating systems. They weren't and still aren't designed to be general application execution environments.