4 ms·

Framework != library. A framework is defined by a DSL or all encompassing architecture that has an opinion on how you structure your app. Frameworks trade choic

Framework != library. A framework is defined by a DSL or all encompassing architecture that has an opinion on how you structure your app. Frameworks trade choice for supposed convenience. Libraries are just collections of functionality that you can mix or match. Good libraries are framework or paradigm agnostic and are very unmagical in their interface. Libraries are replaceable, frameworks are usually not. In Go, if you use an interface to abstract the library calls you need (which is trivially easy to do) you can easily replace any library in your code. But ditching Rails is a ground up rewrite of your entire application and chances are you have read entire books on Rails so switching is going to cost you a lot.

treis 8y ago
This doesn't accurately represent what Rails is today (or has been for quite a while). Most of its functionality comes from libraries that you can replace as you see fit. You can easily build your own "Rails" if you want by using libraries. >Frameworks trade choice for supposed convenience. It's not just convenience. By coalescing on one standard set of libraries it becomes much more likely that those individual libraries will be maintained. >Libraries are replaceable, frameworks are usually not. In Go, if you use an interface to abstract the library calls you need (which is trivially easy to do) you can easily replace any library in your code. But ditching Rails is a ground up rewrite of your entire application and chances are you have read entire books on Rails so switching is going to cost you a lot. What you describe in the first half is effectively recreating Rails. Expending that initial cost in order to avoid the possibility of expending it later doesn't make sense. And you're not right about the cost of switching from Rails. You can use pretty much all the code you write without Rails. The effort will come in creating whatever it is you want to use to replace Rails.

treis 8y ago

This doesn't accurately represent what Rails is today (or has been for quite a while). Most of its functionality comes from libraries that you can replace as you see fit. You can easily build your own "Rails" if you want by using libraries. >Frameworks trade choice for supposed convenience. It's not just convenience. By coalescing on one standard set of libraries it becomes much more likely that those individual libraries will be maintained. >Libraries are replaceable, frameworks are usually not. In Go, if you use an interface to abstract the library calls you need (which is trivially easy to do) you can easily replace any library in your code. But ditching Rails is a ground up rewrite of your entire application and chances are you have read entire books on Rails so switching is going to cost you a lot. What you describe in the first half is effectively recreating Rails. Expending that initial cost in order to avoid the possibility of expending it later doesn't make sense. And you're not right about the cost of switching from Rails. You can use pretty much all the code you write without Rails. The effort will come in creating whatever it is you want to use to replace Rails.