The best answer full of mistakes in Yahoo! Chiebukuro was too ... So I'm writing. https://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q10236599945
The author didn't look up information that he didn't know well, and he heard it before or somewhere. It seems that the answer is based on the information that I feel like I have read it.
I do not think about the possibility of spreading false information on the net by answering with the information I remember At this point, if this author is a technician or someone who wants to be a technician, I would rate it out.
(By making heavy use of "should" and "think", this author answers with information that he remembers. I feel like I'm doing it, but I don't seem to have any problems with answering with the information I remember. It's like putting up a precautionary line in case the information you remember is wrong. .. ..
Even if "should" and "think" are frequently used, the questioner or reader may mistakenly recognize the information as correct. I think that it may be misinformation because I added "should" and "I think", and it is okay to write with information that I remember. Is a mistake.
The questioner of this question seems to have misunderstood the misinformation written in the memory as correct information. )
As long as I write on the net, I don't write with the information I remember, but whether the information I remember is correct. Catch up on the latest information on the net, verify it against that information, and then correct the information. Should be written based on, especially for engineers. The same applies when posting to Qiita etc.
(This question was posted on 2021/01/01 and was closed that day, The best answer full of mistakes cannot be corrected with another answer It has become.
From a disappointing point of view, the poster of the question and the author of the best answer are the same person. It can also be said that the wrong information is intentionally exposed on the Internet. )
With Ruby3.0.0 RBS/TypeProf, a base for type checking, Parallel / Parallel Processing Ractor & Fiber Scheduler Is included. .. ..
Although it is still an experimental function, JIT has been introduced since Ruby 2.6, and even in Ruby 3.0 It's still being improved, but it's a new feature that meets the demands of the times, isn't it? It's not a language specification, but a new feature of the execution environment. .. .. (Even with 3.0.0, performance may still drop in combination with Rails There are many, and it is judged that it has not reached the level that can be put into actual battle? Then it is off. )
Ruby3.0.0 and other new features. https://techlife.cookpad.com/entry/2020/12/25/155741
Information that can be caught up immediately by google with "Ruby new features". .. ..
Ruby original author Matz said that there are no major changes in the syntax, And ... I don't make a big change in the language.
Matz officially has the nuances of changing and evolving Ruby with the times. I am making a statement.
(Ruby is 1.8 → 1.9 → 2.0 (released on 2013/02 almost 8 years ago), which is quite big With painful changes, the implementation of the execution environment is also from the previous interpreter It has been replaced by the bytecode interpreter. Rails will move to 2.x Since it corresponded to 2.x in a relatively short period of time, it seems that it was completed in a relatively short period of time (several years?) I feel it.
Python is 2.x → 3.x, with a wide variety of fairly large changes, 3.0 was released 12 years ago in 2008/12, but 2.7 is in 2020/01 Despite becoming EOF (End Of Life), it is widely used and The migration to 3.x is not complete.
For example, gn, the build tool for Google Chrome, is still 2.7? As it is written, there seems to be no sign of moving to 3.x.
Perl planned a painful change that was too big in 5.x → 6.0, The development of 6.0 has been stagnant for many years, and after some progress in implementation, after all It was renamed from Perl 6.0 to Raku and changed to another language.
Major changes to language specifications are very painful (great pain for users) (Force), so unless it is a change in a way that meets the user's request If you can't show users more than pain, the transition won't progress Therefore, the creator of the specification should ponder it before implementing it. It seems that you need to hear the user's voice. )
Like the best answer above, the information you've heard, feel like you've read somewhere, and remember Based on, I feel that "Rails is Owakon" is often written or said.
In Ruby, before Rails appeared, such a web application framework (WAF) With the advent of Rails, Ruby has become one of the options for web application development for the first time.
Rails has a relatively high degree of perfection from the beginning, and it has been upgraded while responding to changes in the times. Even if WAFs other than Rails appeared, there was no such thing as perfection that surpassed Rails or Rails. So Rails has been the de facto WAF for Ruby.
The de facto Rails ecosystem has been fostered to reinvent the WAF and for other WAFs. It is more widely used in the world to develop a library for Rails than to develop a library. Due to the situation, many libraries for Rails are still being developed.
If there are many WAFs with similar perfection like PHP and Python, there will be a library for the same purpose. It exists for each WAF, and the number of projects on GitHub will inevitably increase.
In the case of Ruby, WAF development is mostly concentrated in Rails, so for Rails for the same purpose Even if there are multiple libraries, the number of WAF related GitHub projects is larger than that of PHP and Python. It is decreasing.
Therefore, the number of Ruby / Rails projects on Github is smaller than that of PHP / Python. It is nonsense to cite that as one of the grounds for "Ruby / Rails is Owakon".
By the way, do you all love it? It is built on GitHub and Rails (Ruby). https://www.publickey1.jp/blog/19/githubrails_69.html
Yesterday (January 19, 2021), support for Ruby on Google Cloud Functions was announced. https://www.publickey1.jp/blog/21/google_cloud_functionsruby.html
Continued & elaborating ...
"Ruby / Rails Owakon" that the front end of Rails looks like a legacy I feel that it is one of the grounds for, so I will write it.
Even now, by chance, the code that Ajaxizes with the combination of rails-us, remote: true, and js.erb, As you can see in a new article on Qiita etc, even people who maintain the code written in the past Unless you're in a Rails project, you're almost gone.
Building a front end with only the features included in Rails is no longer the best solution Instead, it's a legacy style.
Client-side JS framework for Vue.js, React, etc via Webpacker (Webpack) It has become mainstream to build a front end in combination with.
DHH last month was an evolution of Turbolinks Turbo (JS), a client JS framework We announced Hotwire, a new mechanism that combines Stimulus2.0 and Rails. Currently in beta.
Hotwire https://hotwire.dev Breaking News: An Overview of "Hotwire" Released by Basecamp https://techracho.bpsinc.jp/hachi8833/2020_12_24/102368
It's currently unclear if Howire will be a Rails feature or will be offered separately from Rails. Maybe it's provided separately from Rails. (Turbo, Turbolinks went into maintenance mode with the announcement of Turbo, Turbo Drive (equivalent to Turbolinks) for Rails apps that use existing Turbolinks It needs to be included in Rails, so it should be included in Rails. )
A low-cost legacy front-end built with only the features included in Rails? Sell what you can do modern? Seems to be doing.
Hotwire, like the combination of rails-ujs + remote: true + js.erb, Use html (code fragment) instead of json, rails-ujs + remote: true + js.erb I think it can be said that it is an evolutionary type of.
A project with many engineers who have only touched Rails, Hotwire, popular, I think.
Revisioning & continuing ...
Recommended Posts