CoffeeScript與Ruby的比較
If you are subscribed to our Arkency newsletter (we send an email every week or two with some interesting links and our comments), you probably noticed that there is an ongoing debate in our team - whether CoffeeScript. (actually JS) has a good standard library.
I have recently watched an interview with DHH about his opinions on Single Page Applications.
DHH was explaining why they don't go the SPA way with their new 37Signals applications. They chose to generate JS and HTML on the backend and send it back to the client.
One of the DHH's arguments was that they prefer the Ruby stack (with Rails) than the experience of writing CoffeeScript. application, with the server being just for JSON API.
Overall, I think that DHH makes some good points, but I don't agree with the assumption that it's better to work with the Ruby stack than with CoffeeScript. Sure, the patterns are not so mature as with a typical Rails app, so sometimes it takes more time to do the same thing, however their approach of sending JS is also not the most trivial one and it creates a complex architecture, IMO.
First, the syntax of CoffeeScript. is better to me, than the Ruby syntax. This is subjective and I'm not expecting everyone to agree. To me, it's enough that the code is mostly shorter while still very elegant.
Second, the libraries. Yes, JS stdlib is almost non-existing. It's almost always better to avoid the existing stdlib and rely on sugarjs or underscore. Ruby is winning here. Now. With the growing JavaScript. communities, we'll see a huge improvements very soon. The sugarjs library is already awesome and I don't feel I'm sacrificing anything by using it, compared to the Ruby libs.
You can improve the libraries, but it's hard to improve the syntax.
I may agree with DHH, that the SPA environment is not yet at the same level as Rails is now. Even DHH says that the situation happening with JS MVC is a huge shift. In my opinion (and not only mine), we see a revolution that can be only compared to Rails in 2004-2005. Back then, Rails also wasn't that mature, but we were able to use it and have a really well working applications (my first production Rails app was released in April 2005 and was used by hundreds of users every day).
Back to the title dilemma. Is CoffeeScript. better than Ruby?
We need them both. The trend of SPA will be growing and we can't use Ruby there. On the other hand, it's not easy to use CoffeeScript. on the backend (nodejs based solutions are nowhere near the stability of Ruby solutions) and Ruby is a great choice in there. In most of the apps that I'm currently working on, I spend like 80% of my time with CoffeeScript. on the frontend and 20% on Ruby on the backend. That's my answer :)
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/301743/viewspace-742123/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- Ruby程式語言與Ruby之間的比較
- CoffeeScript攻略1.2:比較範圍
- ruby4種比較符號符號
- 通過 for 迴圈,比較 Python 與 Ruby 程式設計思想的差別Python程式設計
- PostgreSQL與MySQL的比較 - hackrMySql
- MVVM與MVC模式的比較MVVMMVC模式
- XTask與RxJava的使用比較RxJava
- JavaScript 與 Java、PHP 的比較JavaScriptPHP
- Hadoop與Spark的比較HadoopSpark
- CMM/CMMI 與敏捷的比較敏捷
- Hibernate與 MyBatis的比較MyBatis
- SQL、Linux 指令碼與 Ruby 之比較 ZTSQLLinux指令碼
- Vue與React比較VueReact
- 【Redis與Memcached比較】Redis
- RecyclerView與ListView比較View
- js與jq比較JS
- PostgreSQL與MySQL比較MySql
- Vuex與Redux比較VueRedux
- Go 與 C++ 的對比和比較GoC++
- oracle中字串的大小比較,字串與數字的比較和運算Oracle字串
- Go與C#的比較 - RedditGoC#
- Flutter與React Native的比較FlutterReact Native
- Docker 與 Podman 容器管理的比較Docker
- OSI模型 與 DOD模型的比較模型
- Hibernate與 MyBatis的比較(轉)MyBatis
- ORACLE的count與空值比較Oracle
- sap與ORACLE的ERP比較Oracle
- C與I型別的比較型別
- Querydsl與JPA標準的比較
- React與Vue模板使用比較(一、vue模板與React JSX比較)ReactVueJS
- Flutter 與 iOS 功能比較FlutteriOS
- Flutter與Swift比較 - evroneFlutterSwiftVR
- Hibernate與mybatis比較MyBatis
- Python 與 Javascript 比較PythonJavaScript
- POWER BI - 與其他BI工具的比較
- Mysql中的Btree與Hash索引比較MySql索引
- Apache與Nginx的優缺點比較ApacheNginx
- PostgreSQL與Rust的聚合實現比較SQLRust