4 ms·

Let's say I don't want to ship out my whole application package until a user has logged in, so I go to implement a static HTML login page and signup page. Uh oh

Let's say I don't want to ship out my whole application package until a user has logged in, so I go to implement a static HTML login page and signup page. Uh oh, I have no template engine! Well just use ERB with Sinatra you say. Fine, cool, I have my form all set up. But wait, how do I tell the user one of their supplied fields is invalid? No build in form validations! Darn. Guess I have to manually code that in. Cool, done. Now lets say I want to let the user know they have signed in successfully. Oh wait, no built in flash mechanism. Cool, I guess I could use Rack::Flash. Or, maybe just the framework that solved this stuff many years ago.

endlessvoid94 15y ago
> Uh oh, I have no template engine! The whole point of this post was using a complete frontend on the client side. Like backbone. You don't render backbone using a server-side template -- it's all done on the client side. I'm not saying throw out all your old tools. I love using Makefiles. I'm saying use the right tool for the job -- and my opinion is that to have a separate client side app like backbone and a simple server-side API, Rails is way overkill.
bradgessler 15y ago
You're missing the point. The discussion is that some sort of JavaScript stack is handling that stuff and the sever maintains no view state. The benefit is that you can have a more responsive web app that you can easily throw on a CDN and have a snappy end-user experience.
- hbrundage 15y ago
  I wholeheartedly agree that for web applications client side applications are the way to go and spend all day every day working on one which we are as you said going to throw on a CDN. I argue however that the experience of sending down the whole asset package (or parts thereof) just to show the login page or other assumedly tertiary screens of the application is worse than rendering that server side and sending it back lickety split. There are other use cases too, you might want to leverage Rails' ability to pump out both XML, and JSON, and maybe capitalize on how easy it is to add new formats like CSV. My point is that you lose _so much_ flexibility to do anything at all server side by ditching Rails that it simply isn't worth the performance increase until you are absolutely sure you should switch and that your requirements are stable. If this is the case it might even be time to ditch Ruby for something more roflscale. With regards to your other comment, I again disagree. To me it seemed like you were advocating switching off Rails because you were no longer using it's view rendering bits. I say balderdash, as above, I think you will run into weird unforeseen situations which you don't want to implement client side. To your ecosystem point, indeed, decoupling progress has been made and its wonderful to see. It's great for Rails to have stellar competition, but the reason I started using it in the first place is that it took 15 minutes to make a blog. It just works. Smart people have made decisions about what ORM and tempting engine and test framework to use, and how to architect it all in such a way that my teammate and I both know where to find something to change it. I don't want to have to make all those decisions and make all the same mistakes Rails did before arriving at the happy middle ground it has, and I want my teammates to just be able to jump into my project and know how to use the thing.

endlessvoid94 15y ago

> Uh oh, I have no template engine! The whole point of this post was using a complete frontend on the client side. Like backbone. You don't render backbone using a server-side template -- it's all done on the client side. I'm not saying throw out all your old tools. I love using Makefiles. I'm saying use the right tool for the job -- and my opinion is that to have a separate client side app like backbone and a simple server-side API, Rails is way overkill.

bradgessler 15y ago

You're missing the point. The discussion is that some sort of JavaScript stack is handling that stuff and the sever maintains no view state. The benefit is that you can have a more responsive web app that you can easily throw on a CDN and have a snappy end-user experience.

hbrundage 15y ago
I wholeheartedly agree that for web applications client side applications are the way to go and spend all day every day working on one which we are as you said going to throw on a CDN. I argue however that the experience of sending down the whole asset package (or parts thereof) just to show the login page or other assumedly tertiary screens of the application is worse than rendering that server side and sending it back lickety split. There are other use cases too, you might want to leverage Rails' ability to pump out both XML, and JSON, and maybe capitalize on how easy it is to add new formats like CSV. My point is that you lose _so much_ flexibility to do anything at all server side by ditching Rails that it simply isn't worth the performance increase until you are absolutely sure you should switch and that your requirements are stable. If this is the case it might even be time to ditch Ruby for something more roflscale. With regards to your other comment, I again disagree. To me it seemed like you were advocating switching off Rails because you were no longer using it's view rendering bits. I say balderdash, as above, I think you will run into weird unforeseen situations which you don't want to implement client side. To your ecosystem point, indeed, decoupling progress has been made and its wonderful to see. It's great for Rails to have stellar competition, but the reason I started using it in the first place is that it took 15 minutes to make a blog. It just works. Smart people have made decisions about what ORM and tempting engine and test framework to use, and how to architect it all in such a way that my teammate and I both know where to find something to change it. I don't want to have to make all those decisions and make all the same mistakes Rails did before arriving at the happy middle ground it has, and I want my teammates to just be able to jump into my project and know how to use the thing.