Rails 学习 Ruby 的一些感慨，身虽远离，但心未存走远。
一开始进公司，我什么都不懂，老板只给了一本 ruby on rails web 的书，就开始工作了，虽然现在的水平也只是一般般，但是我喜欢 rails 的快捷。但是也正是这种快捷，让我感到了孤独，烦躁和不安，英语水平是硬伤，这就不吐槽了。rails 的定制化太弱了。我吐槽的就两点，一是那个鬼斧神差的 api，真难懂，类型的什么都没有，还有就是定制化，rails 的定制化真的是差的无力吐槽。就拿 smiple_for 在 rails 中的使用。哎，我不知道是我不会用它还是什么情况，从数据库中迭代一些多组 radiobox 出来，然后修改每个选框的 id 为数据库属性，就这点问题，硬是整到崩溃。反而用 form_tag，秒解。就这点，让我决定给表单绑定规定是快捷了。但是定制化真的是要人命。就想买汽车，大家都买 suv 突然有人来要买大货车，rails 这个时候就痛苦万分。捆绑试的语言让人窒息的感觉。调去搞 java 项目了，暂别了，哎，也收到了入职邀请。心有不甘。
Rails is omakase. Rails 无法做到让每个人都喜欢它，你喜欢就用，不喜欢也不必强求自己用，但是在不了解 Rails，甚至用错 Rails 的时候，批判和吐槽是不是过于偏激了，对 Rails 来说是不公平的。
楼主还未入门便已放弃。
楼主有两点值得列出评判一番：
Ruby 动态类型 VS Java 静态类型
起初是静态类型的天下，但限制实在太多，聪明的人越来越多，他们不想为了一句话能解决的需求，反而写一堆无用的类型声明。
Rails 是它的极致产物，君不见，Ruby 元编程强 Java 元编程 100 倍。
请接受便捷，控制风险。
FormTag VS SimpleForm
不得不说，web 开发有一半时间都在搞 form 表单处理的事情是不为过的。Rails 为我们做了很多事情：
- csrf 安全
- utf8
- 一堆 helper 方法简化编写复杂度
- 复用 edit 与 new 时
- 上传文件的预处理
- SJR 处理支持
以上适用于所有场景。
更甚者，simple_form 直接从数据库映射出数据类型。极简开发 form 表单，但不适用于所有场景!!!
它适于简单表单处理。面对于定制性强的时候，用 Rails 的 helper 是最简单的。Rails help 也不是所谓的 xx_tag, 而是 form_for.
如果你用别的框架，对不起，请用类似于 xx_tag 的方式处理，所有事情自己安排。
综上，楼主还未入门便已放弃。但这个过程是正常的，只有深入底层搞 web 开发后，发现繁琐的事情后，才能想起 Rails 的好处。不然一开始就进入 Rails 的怀抱中，幸福是不自觉的。
rails 之前我用的是 flask，刚开始学 rails 也是觉得浮躁 路由什么的定制都好麻烦；但现在知道一些概念：标准、习惯 
原来觉得自己定制了老牛逼了 后来发现是自己意淫作怪，那些定制并没什么卵用。
随着越多了解一些特性其实当时的所谓定制都能实现 而且很简单方法就实现了。
有机会参加下当地的 Ruby 社区聚会，当面交流实地看看老手的做法。 另外 Rails 不仅是定制性强，之前因为给 iOS 客户端上实现 自定义 URL 跳转，研究过市面上各语言流行 Web 框架的路由匹配实现，Rails 的思路不仅新颖，而且高效，没有看到其他框架能达到这个高度的。
入门难还是因为领域内的知识不全面，Flask Django 和 Rails 的设计还是有些差距，倒是 PHP 的众多框架，ASP.net MVC 和 Rails 有很多相似的理念（其实不少都是抄的 Rails...），入门起来就很快。一方面是框架的一方面也是 Web 开发相关的吧。
至于你说 form 的问题，Rails guide 的文档里写的非常清楚...
本来是不太想回复这个帖子的。但随手点看楼主的个人资料，看到了发的其他一些帖子，感觉还是想来说两句。
楼主几乎所有的帖子里，都让我看到了一种表现——表现于二本学校 CS 大一大二学生身上的——浮躁。（我并不是在黑学生们，学生们请不要自认为躺枪） 我认为，除非楼主也是这个阶段的人，这种浮躁显得太不和身份了。
在你所有的提问中，虽然没有直接看到伸手党的影子，但：
- 问题描述不清
- 一看就知道没有去网上搜索，那些问题只要在网上找，都有现成解答
- 基础不牢，概念不清
- 自己动手能力不是很强
- 本帖中的错别字是什么鬼？
你要知道（估计你原本不知道），Rails 是在世界上排名第一的 Web 框架，LinkedIn、Twitter 等网站最开始就是用 Rails 搭起来的。 然后你自己驾驭不了，反倒说是 Rails 的缺陷，更说核心开发团队固步自封，还在试图争辩什么“核心团队面临的需求与问题”。
Rails 有没有自己的诟病或缺陷？有。但你不知道，你对 Rails 了解的这种肤浅的程度，怎么可能知道？ 核心团队有没有遇到需求与问题？我相信也有。但你不知道，你并不是核心开发团队的，你怎么可能知道？ 你自己有没有问题？有，问题如上。但，你自己也不是很清楚；你明明应该了解、剖析清楚——但你就是不清楚。
你没有仔细阅读 Rails 文档，没有尝试做过各种 Demo，没有专门研究并学习过 Ruby 语言，也没有读过很多技术规范、标准——从你的提问中，我都能看出来。
浮躁、肤浅、能力不足，我还能说什么？ 如果你的心真的未曾走远，希望你在这里的收获不仅仅是 Ruby on Rails，还有一种做技术的姿态。
为何要用 form_for，看看我 4 年前发的一个小技巧：
https://ruby-china.org/topics/4972
所以，不是那些东西不好用，而是你目前需要做的事情太初浅，你理解不到这些东西存在的价值。
simple_form 则是更上层的东西，它能帮你统一解决：
- Label 的名称
- 每行表单的统一格式（实际每个项目绝大多数表单结构都是一样的），同时利用统一调整表单结构
- I18n 管理方式的 Placeholder 和 说明文字（hint）
- 更简单的使用方式，绝大多数情况只需要一行，例如
f.input :name - 在你不需要的时候，你还可以混写 Rails 默认的 form 写法或 HTML 写法
- 突然有天要从左右布局（Label 左、文本框右），变成上下布局
例如 GitHub 个人设置这个场景 https://github.com/settings/profile，用 simple_form 能让整个网站有一个非常固定、稳定、不会因为有个别人漏写了几个标签或 class 导致样式不统一的问题。
当然，simple_form 不是适用于所有的场景，如果你的项目表单结构总是不固定的（我认为这是设计有问题！），你不需要它。
用 simple_form，前端不懂 ruby 就看不懂
截取自 rails 5 开发进阶 按照代码结构上，可分为四类：
- Form Builder
- Form Helper
- Form Options Helper
- Form Tag Helper 按照使用方式不同，又可分为三类：
- Form Builder 对 Model 依赖最重，表单对象几乎等价于 record 对象。
- Form Helper 和 Form Options Helper 次之。
- Form Tag Helper 对 Model 依赖最轻，没有表单对象的概念，操作上几乎等价于 HTML（其实就是语法糖）。
刚刚学习 ruby on rails，感觉功能强大，公司里都是各种 Gem 插件，确实头痛。但是发现 ruby 语法好像挺“简单”，但是 rails 却变化万千。
#18 楼 @u1440247613 你也可以完全不用，纯写 html。对比下哪种更繁琐。你也可以涉猎其他 web 框架，PHP 的，Java 的，go 的，nodejs 的，对比下 是否有像 rails 这样定义 view 层的 helper 渲染方法，再看是否“恶心“
[老板只给了一本 ruby on rails web 的书] , 老板如果一本都不给，或者不给你来个 1 对 1 喂饭，你就没办法了吧？ 鬼斧神差是什么玩意？ 类型的什么都没有，你在讲笑话？ 很奇怪某些人，不爱一个玩意，偏到这玩意的爱好者社区去发一些低级的牢骚，究竟图的是啥？
从我学习 ruby 经历来看。直接不学明白 ruby 就学 rails.真容易从入门到放弃，rails 高度抽象，总结了各种最佳实践，但是它看似简单，其实很复杂，我就没有着急写东西，而是打好 ruby 基础，多看一些书籍耐心了解 ruby 和 rails.
ruby 看似脚本语言。入门门槛很高的.就好比你是一个篮球初学者。上来就学各种复杂跑位战术和花式单打技巧.你也会感觉有心无力
