71–80 of 143 posts
As Smalltalk creator Alan Kay said: "Once you have something that grows faster than education grows, you’re always going to get a pop culture." This is so true in so many levels, that I feel I bit sad just thinking about it.
Earlier quoted context omitted.
You don't have to use Bundler. Just delete the Gemfile and manage the dependencies yourself.
The problem is that there's no third option- something to manage dependencies that's not bundler. We all want and need dependency management, but bundler should not be the One True Solution.
Earlier quoted context omitted.
The problem is that there's no third option- something to manage dependencies that's not bundler. We all want and need dependency management, but bundler should not be the One True Solution.
I've used Isolate[1] pretty happily on a few things (command-line tools and/or Sinatra apps). I haven't tried it with Rails, so I can't speak to how well it works in that context. But the readme's first example is Rails, so it's worth a look if you really want an alternative. [1] https://github.com/jbarnette/isolate
tl/dr What I take from the post: Guy has no fun with underlying technology, rewrites from scratch with more fun framework, does not care about current users, thinks this is offset by future users who can more easily use coffeescript.
what zed said about him is not absolutely wrong http://oppugn.us/posts/1276150607.html
... as was the code that zed linked to - https://github.com/gilesbowkett/archaeopteryx/blob/0b08ebdb9...
Rails is very suited to big API projects now - but there is no escaping the fact that all the action is moving clientside. The Rails learning curve is now very steep for new users and the accusation that it has become all it set out to solve is a fair one. For me it's a mature/stable framework and ripe for using commercially now, but I can understand the new kids gravitating to something more disruptive.
agree plus add Rails is very well suited for the client side hotness with the asset pipeline in Rails 3. However I just tossed Rails after many years for 2 primary reasons: 1) Anything that might take a sec or more has to be moved out of the request cycle and into a background process. That just gets annoying after a bit. Node.js can serve requests, grab data from to world's slowest API's, send emails, etc, all from…
> For the project I'm working on now, I had to make my own
> asset pipeline. It uses less for css (and bootstrap),
> precompiles handlebar templates and concats all the js
> into a single file and uglifies it. Cost me 2-3 hours,
> about the same time it took me to learn Rails asset
> pipeline and was about 10x more fun.
Earlier quoted context omitted.
After everyone saw how it easy it was to write your own blog in Rails, everyone ... used Wordpress anyway. The Rails use case was always truly limited. I still don't know any application that achieved maturity and stayed coded in Rails. For a while that was Twitter, but then they started moving stuff over the jvm. Node will probably end up in a similar way, because at the end of the day no one wants to manage thousan…
In my experience with Ruby development (2 years), I have never, ever experienced a single issue caused by duck typing. Static typing is great for performance, but it has nothing to do with being able to maintain a project.
tl/dr Rails is not the new hotness anymore, the Rails 3 rewrite was a waste of time and it's strayed far from its initial ease of use. Node & Coffeescript, the new hotness, are awesome, here's my new video series, the first one's free.
Personally, it feels a bit revisionist, because I distinctly remember the Rails fans in 2006/2007 talking about how easy Rails made web development. But... perhaps my mind is playing tricks on me as I get older.
Earlier quoted context omitted.
agree plus add Rails is very well suited for the client side hotness with the asset pipeline in Rails 3. However I just tossed Rails after many years for 2 primary reasons: 1) Anything that might take a sec or more has to be moved out of the request cycle and into a background process. That just gets annoying after a bit. Node.js can serve requests, grab data from to world's slowest API's, send emails, etc, all from…
> For the project I'm working on now, I had to make my own > asset pipeline. It uses less for css (and bootstrap), > precompiles handlebar templates and concats all the js > into a single file and uglifies it. Cost me 2-3 hours, > about the same time it took me to learn Rails asset > pipeline and was about 10x more fun. Sounds familiar: http://documentcloud.github.com/jammit/
Rails is very suited to big API projects now - but there is no escaping the fact that all the action is moving clientside. The Rails learning curve is now very steep for new users and the accusation that it has become all it set out to solve is a fair one. For me it's a mature/stable framework and ripe for using commercially now, but I can understand the new kids gravitating to something more disruptive.
agree plus add Rails is very well suited for the client side hotness with the asset pipeline in Rails 3. However I just tossed Rails after many years for 2 primary reasons: 1) Anything that might take a sec or more has to be moved out of the request cycle and into a background process. That just gets annoying after a bit. Node.js can serve requests, grab data from to world's slowest API's, send emails, etc, all from…
On 2) I use CoffeeScript and Ruby at once and that's not an issue for me.
I agree Rails has evolved to become many of the things that DHH first complained about in so-called Enterprise frameworks. But that's because a wider audience has wider problems to solve than Basecamp 1.0. At the end of the day, Rails 3.2 for all its complexity still "gets" server-side web development better than the antiquated Java frameworks that it replaced ever did. What Rails really never got was client-side dev…
I'm not sure. You only need a server-side if you have users, there are a lot of apps that don't need users. For those that do there's no reason why your server-side code needs to sit next to your web server as it does today. What you need is a good API framework, which Ruby does well today, but perhaps should be its primary focus in the future.