Wednesday, November 14, 2018
I mostly agree with Walter, but:
>The kinds of JS (ES6, React, Vue) you would write for the front-end are markedly different than the kinds of JS (Express, SQL/JSON DB) you would write for the back-end.
is just like
>The kinds of Ruby (controllers/ERB/templating/stimulus) you would write for the front-end are markedly different than the kinds of Ruby (Rails Models/ActiveRecord) you would write for the back-end.
At the end of the day, they are more similar than they are different. What you really need to go to the "lot" and test drive the "car":
Ruby on Rails (stock): https://repl.it/@jakeNiemiec/RecursiveResponsibleOperatingsystem
"Node.js" (express + sqllite): https://glitch.com/edit/#!/smiling-thing?path=server.js:1:0
Above are 2 different sandbox platforms that you can test out the ergonomics of the frameworks. At the end of the day, they both "abstract" away concepts like:
- Given "route" `/`, render or send 'index.html'
- Given "resource" `/some_resource`, build a SQL query to query the DB and render/send it back as JSON
Just steer clear of anything that claims "zero-configuration". Abstraction comes at a cost and you are bound to the choices that the framework/library author made. Generally, both Rails and Node.js are very liberal in this way.
All that being said, it all comes down to: features vs cost. Rails is more expensive to host & more expensive to develop for, but that expense is negligible if you need a complex app. If you are just making a CMS I would take a look at this table: https://www.gatsbyjs.org/features/ (compares features/links from multiple cms tools)
On Wed, Nov 14, 2018 at 8:23 AM Walter Lee Davis <waltd@wdstudio.com> wrote:
> On Nov 13, 2018, at 9:42 PM, Jack Waugh <jv2a9g4794@snkmail.com> wrote:
>
> It's late 2018. Is Ruby still what managers are turning to for significant numbers of new web projects?
>
> Are there sets of requirements that are so simple, that almost everyone with any experience would choose some other stack not involving the Ruby language? E. g. a web site requiring a CMS and a 'blog and little to nothing in the way of custom tables?
>
> I'm not experienced with many kinds of projects on the Web, and so I have this maybe naive thought that with nodejs, at least people can use the same syntax for code that runs on the server and code that runs in the browser. Doesn't having that single syntax reduce the intellectual burden somewhat? If Ruby is still getting a lot of traction for new projects, what are said to be the benefits that outweigh the drawback of using two languages and so having to keep mentally changing gears?
The kinds of JS you would write for the front-end are markedly different than the kinds of JS you would write for the back-end. They have different concerns, and so they are expressed differently in code. The language you choose is akin to the alphabet, the words and sentences you need to compose with that alphabet are fundamentally different depending on the task at hand, and the head-space you occupy as a developer when writing must be as well. Those conceptual differences are far more important than the syntax and libraries you use to express them in code, so they should drive the choice of language and framework.
The "same code in server and browser" has always felt like a false syllogism to me. You wouldn't use the same vehicle to haul a load of bricks to the dump as you would to win a road race, would you? Ruby has a settled, mature standard library and rich and expressive tooling for Web applications in Rails. If you wanted to build a SPA, you might choose Node or Ember or Vue.js, backed with an API in Sinatra. If you wanted to build a vanilla-standard blog, you might reach for Wordpress. In other words, use the best tool for the job.
"Consistency is the hobgoblin of simple minds."
Walter
>
> --
> You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-talk+unsubscribe@googlegroups.com.
> To post to this group, send email to rubyonrails-talk@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/b40750b4-8136-4f27-931e-c75950b5e9d5%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-talk+unsubscribe@googlegroups.com.
To post to this group, send email to rubyonrails-talk@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/E77022A1-FE9C-46D6-A517-07A176484166%40wdstudio.com.
For more options, visit https://groups.google.com/d/optout.
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-talk+unsubscribe@googlegroups.com.
To post to this group, send email to rubyonrails-talk@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/CALn2xuDG2irCd0SjTLBjufZ6NQYR-uJf6Sjq4SYk-XJh%2BWGP7w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment