Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I'm a studying CS and lately I've got myself really enjoying learning about web development..
Now, I have tried to learn AngularJS for a few times but then I wanted to focus more on backend first, since I already know the stuff like html/css/js which makes good part of frontend so wanted to see what backend feels like..
So I started learning Rails.. Now, since with my previous attempts of trying to learn AngularJS I learned that it is all about MVC, sending data from one to another etc.. My problem is, at first glance at least, Rails seems to work in the really similar fashion. The question is, why would anyone want to use both AngularJS and Rails at the same time, when, at least in the newbie's eyes -> Rails seems that it can handle both backend and frontend? Like, views are our frontend, and we can use css/js in those .html.erb files, wouldn't that be considered frontend after all?
Now, I'm almost positive there is a good answer to this since googling "why use angular with rails" usually comes with results of tutorials that explain to you how to integrate them, I just want some reasons so that I wouldn't be as confused as right now..
Thanks!
Rails is a server-side framework that produces HTML, JSON, and JavaScript as well as manages CSS and image assets.
AngularJS is a client-side framework. Generally, without a server component it really can't do much.
By default Rails doesn't have a client-side framework. You can use EmberJS, Angular, or others to make your client-side interface more responsive and flexible. Rails alone can't do this, it can't run in your browser.
Likewise, AngularJS can't run on your server. You need to combine them.
MVC at frontend is a recent development. Earlier days we used to develop everything at backend and use frontend only for animation, UI etc.,
Slowly with Ajax introduction we started doing more at frontend and less at backend.
Now we migrated completely to frontend. We use backend only for logics which should be decided at server side and database management.
Single line answer, we need rails or any backend only to serve few logics which SHOULD happen in the backend, User can change the logic if it is at client side. So we force them to happen in the server side. And ofcourse database should be at the backend.
Other than that , there is absolutely no need to use rails views and others.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I have spent alot of time developing on sinatra, and that has worked fine for me because I have only worked on small projects and scale has not been a problem. Now I have the need to use rails, and the structure is a little confusing to me. I understand that when I type localhost:3000/images rails looks for the route in routes.rb (e.g. get 'images#index'), then goes the the controller images then in images looks for a index function, and finally finds the index view and renders it.
Why are all of these changes necessary? Couldn't it be simpler like sinatra (which seems to just include the controller step in the main file)? In an answer I am looking for why it is better to do it the way rails does it including specific reasons, advantages and disadvantage with examples.
Thanks in advance!
Konstantin Haase is the current maintainer of Sinatra and feels that they both cater for different types of application:
They are both solving a different set of issues, even though they
indeed overlap. While Rails is a framework focused on writing model
driven web applications, Sinatra is a library for dealing with HTTP
from the server side. If you think in terms of HTTP
requests/responses, Sinatra is the ideal tool. If you need full
integration and as much boilerplate as possible, Rails is the way to
go.
David Heinemeier Hansson also believes that there was room for both of them, but feels that is size of your app that should influence which one to use:
Sinatra is great for the micro-style, Rails is not. As long as you
stay micro, Sinatra will beat Rails. If you go beyond micro, Rails
will beat Sinatra.
So, basically, Sinatra and Rails are different and they have different use cases. Rails is an open source full-stack web application framework. It follows the popular MVC framework (Model, View, Controller) model and is known for its "convention over configuration" approach to application development. So, as you can see controller is a part of Rails by design.
You can find many articles describing the differences between Rails and Sinatra and their use cases. Here are couple of interesting blogs:
Rails vs. Sinatra
Rails vs. Sinatra by Example
K M Rakibul Islam's answer is great. You might also check out Rack. Both Rails and Sinatra are built on it. Rack is a web server interface that expects an "app" to be a Ruby object that takes a request hash via a method called call and then to respond with an array that includes the http response code, the http headers and the response body. It's pretty barebones. Looking at Rack might give you a better sense of how the two diverge past that-- if you're interested in "how" rather than "why".
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I'm using yard to generate my documentation for Rails apps from an rdoc file. There are AngularJS documentation generators, but how could they be connected to generate one coherent document for an AngularJS + Rails app?
In this case it is probably fine to have them separated, and indeed may make more sense to have them separated. Angular is going to be solely for your client-side stuff, and I'm assuming you're then using Rails as an API or perhaps a different piece of the app's functionality. Either way, they are fundamentally doing different things, so it would make sense to have them in different doc sections.
You could create a "landing page" for your documentation if you'd like: one button links to Angular docs and one to Rails docs, and that would solve the need to have them both "in one place". Actually figuring out a way to make them overlap in the same system is likely not worth the effort though, and may actually be a worse user experience.
As the previous answer stated, it would be good to use two different tools and link them together.
I would start with something like Apipie or just rdoc to document the ruby stuff. Additionally I would search for a good js documentation generator. This article compares a four different generators, while 'Docco' seems to have a ruby port with that is called 'Rocco', that may be even able to generate documentations for both, ruby and js. JSDoc on the other hand enables you to integrate custom pages into your docs (here you could place a link to the apipie generator).
In general I would probably just go for the rails API doc and have some conventions for commenting your angular code, as the angular stuff probably has no API that is accessible by another part of your system and therefore only needs some internal documentation.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I need to develop an interactive web app with an admin backend. I have thought about using Ember.js for the frontend and Ruby on Rails (with ActiveAdmin) for the backend.
But i have some questions:
1) Should i put the Ember.js app inside the rails project, or having both separate? Is there any performance difference or something i should know about choosing one of the two strategies? I like to have things as clear as i can.
2) Should i use Ember.js and Rails-API instead? I mean... i think i won't use almost anything about the Ruby on Rails project... But i am confused, as i need the Admin Backend...
I have some experience (a little) on Ruby on Rails, but as i am new to Ember.js, i would really appreciate any help you can give me.
I also worked on a similar kind of project, and believe me having two different projects will benefit you a lot.
I used followings:
Sinatra for backend
Backbone.js for frontend
It makes a lot easier to add the functionality in your code, when you use two separate apps.
I recently had a similar project with an Angular app and a Rails backend. I agree with Arslan. Having a Sinatra, Rack or other API is better than Rails.
Using Ember for some parts, and Rails for other parts (like the Admin section) is a bad idea because:
You are doing the same things 2 different ways: getting data, rendering pages, etc.
You would have 2 separate functionalities in within the Rails app: one Rails app and one API.
It is much simpler to run 2 separate apps than to put a Javascript MVC into a Rails app. You end up with complexity in getting the Asset Pipeline to do what you need.
Here's my take:
If you're fluent in Rails, stick with Rails.
Yes, Sinatra or other frameworks may be lighter, but you'd have to handle lots of things by yourself.
As for Rails-API, it's a good project, but it's a bit of hassle at the beginning to figure out what modules were removed, etc. You can make an API with Rails without Rails-API. You can always use Rails-API at a later point if it turns out you need the performance increase.
Use Ember CLI for your client application.
It's the golden path for developing ember applications and using third party libraries. The gem Ember-rails still works and is still maintained, but you should not start a new project with it.
Keep them separate
It simply makes more sense to have them separate. This way, development and deployments of both apps are not tied to each other.
It uses more repositories though, and if you're using github, it may mean you'd have to switch plans. But there are other options such as bitbucket where the pricing is not tied to the number of private repositories
I hope this helps you.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I see some old questions here and here
It is now 2014, and I also have a more specific question.
Another company has built a REST API. Now I want to build a web application that only needs controller and view. I was originally planning to build this with just PHP without the bloat of an MVC framework. Then I was thinking maybe doing it with ASP.NET with just simple code behind and .aspx approach (the non-MVC way). I was even considering using only JQuery and HTML. The reason I haven't really considered a full MVC framework is because I'm simply just sending data, getting data and printing data. I don't have to really implement business logic.
Right now I'm considering doing this in just the ruby language because it seems like such a clean and minimalist language. But is there any advantage to including the entire rails framework? If so, what features are worth considering in the rails framework for my purposes?
EDIT
It seems I got a close vote for opinion based. But I'm not looking for opinions. I'm looking for the advantages of rails framework for my purposes. In other words, what problems can the rails framework solve significantly faster than just using ruby+curl+print_line().
As example on how to answer the question objectively, you can state things like:
Scenario 1:
Rails makes CURL calls and displays in views like so.
Pure ruby make calls and outputs views like so.
Result: As can be seen, rails requires X fewer lines of code than pure ruby as it pertains to the OP's original question
Scenario 2:
Rails handles page caching like so.
Pure ruby page caching will need to be handled like so.
Result: As can be seen, rails require X fewer lines of code than pure ruby as it pertains to the OP's original question
By listing the problems the original rails authors hoped to achieve and solutions they hoped for us to utilize in the situation defined in the OP's original question, we can see quantitatively the advantages Rails has over pure ruby.
Rails is pretty big, and in my opinion you don't need the bloat of Rails for something this simple. Even though it's not an MVC framework, I would recommend something like Sinatra, especially since it doesn't force you to use a database at all. Sinatra is a very simple framework, and it's most useful when you just want a way to easily set up HTTP routing with basic view support. However, note that it is possible to create a model that doesn't use ActiveRecord with Rails.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 6 years ago.
Improve this question
I'm looking to start on a project web 2.0 app for a bit of fun. I'm a little confused as to what sort of backend I will require. The site revolves around a user submitting an item, then other users submitting responses, then rating each response up or down. That sounds a little like digg.com I realise. How do I go about tackling a project like this? Is a ruby-on-rails + MySQL solution a good way to start? I've also read it could be developed using wordpress :S
Are there any guides/documentation/global-tutorials for this sort of thing? I'm very new to web applications and am using this as a learning tool.
Dom
First things first, when starting to learn something like this, read a book.
If its Rails you are interested in, you could probably skip buying a book on databases, but would advise:
'Agile Web Development with Ruby on Rails' - http://www.amazon.com/Agile-Web-Development-Rails-Programmers/dp/097669400X
'The Rails Way' - http://www.amazon.com/Rails-Way-Addison-Wesley-Professional-Ruby/dp/0321445619
For online guides, Rails has its own 'Rails guides' - http://guides.rubyonrails.org/
For a free guide to Ruby you could try the online pickaxe http://whytheluckystiff.net/ruby/pickaxe/
The plus side to Rails is that you have a Ruby API to access your database (in the form of ActiveRecord) where you can skip out (initially) on learning a lot of SQL (not recommended for performance applications, but good for starting with).
My advice is to learn this stuff before you go on to AJAX.
Oh, and skip web development on Windows, go install VMWare Server and install any distribution, though, for ease of use try Ubuntu (unless you are already on a Linux machine / Mac), it will save you lots of development headaches later on, though may be a pain initially. There are guides for getting set up for this all over Google.
As for your question on databases, even though the books may suggest using sqlite, try and avoid it, and go for something like Postgres instead of MySQL, the benefits will become obvious to you once you start looking at more advanced SQL stuff.
You basically need 3 things to build a site like you're looking for.
1) you need a database to store the state of your application. Something like MySQL or MSSQL Express Edition.
2) you need a server side technology like PHP or ASP.NET to handle the communications between the web browser and the database.
3) you need some javascript code in your browser to capture the events and inputs from your users.
A basic flow might look like this:
A user navigates to page and clicks a button which raises a javascript click event. The click event handler makes an AJAX request back to the PHP code running on the server which saves the data to the database.
Use whatever technology you have some familiarity with or whatever you would like to learn. You can do bad job or great job with any technology at hand.
From the description you provide, it should not be that complicated, but you will definitely need to learn some HTML and CSS, and later JavaScript.