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 <https://rubyonrails.org/doctrine/#provide-sharp-knives>. 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/ <https://www.gatsbyjs.org/features/>* (compares features/links from multiple cms tools) On Wed, Nov 14, 2018 at 8:23 AM Walter Lee Davis <wa...@wdstudio.com> wrote: > > > On Nov 13, 2018, at 9:42 PM, Jack Waugh <jv2a9g4...@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+unsubscr...@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+unsubscr...@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+unsubscr...@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.
