If PATCH even has a remote chance of breaking 0.01% of sites, then WHY do it? PUT works fine. I don't care.
Well, this "if it even remotely breaks 0.01%" and "I don't care" attitude is the main reason things get bloated and stop progressing.
Well, this "if it even remotely breaks 0.01%" and "I don't care" attitude is the main reason things get bloated and stop progressing.
There's still serious performance regressions.
The asset pipeline is still sort of a trainwreck.
There's still no automation for schema migrations (perhaps hobo fields will finally bring some relief for those who adopt it).
They still don't seem to have realized that code generators are a no-go.
I see zero efforts towards modernizing the bloated routing and MVC cruft to accomodate modern fat-clients (and imho the "resources"-magic was a terrible idea from the start even for regular apps).
The whole thing is still riddled with ungodly amounts of magic that likes to break in unpredictable ways (my pet bug: the monkey-patch to really suppress browser stack-traces in production changes about every 3 months and it's worrying such a bug was deliberately created in first place).
I could go on for a while... </rant>
To be able to change the direction of Rails on this issue and the other issues the poster above raised, I'd have to spend a significant amount of time submitting patches and get to the point where I am a major committer to have the opportunity to chime in and have a significant impact on the direction Rails is going. Even if I or someone else with the same concerns were committed to making that effort, by the time I or they get to the point where we can have an impact, it will be too late.
I'd rather commit to a node or an npm package than rails because any package I commit to will hopefully be replaced by something better once it's outlived its usefulness. My favorite part about node is that it isn't opinionated. It leaves the opinion to the community modules. Hopefully most community modules with maintain just the right amount of opinion about their domain and know when to concede matters of opinion to other modules that node better. It's nice when separation of concerns is a cultural value.
This isn't a node/rails debate. It's a values debate. I think opinion was the right value for the right time several years ago. We're going through a time of change where opinion is a liability not an asset.
I know that GIT and the like have made it really easy to fork and run, but does this fundamentally help? Does having X versions of some framework really make sense?
Why not go a different route and just give up the one side and make another? Rather than forking, make something new.
Personally, I think there's not. I think people either are sticking to Rails or they are not. I think even if you don't like the new Rails, it did help the development community at large. Before Rails, I don't know many web folks who were talking about TDD and MVC and real, honest, programming stuff.
Yes, it does. What ends up happening in practice is that forks are almost always short-lived. They either get merged with the mainline, they become the new mainline, or they die out. Occasionally, there are two self-sustaining projects that diverge from the same point of origin, but it's rare.
Node is not opinionated because it is not a framework; it is a JavaScript environment built on V8 and some common libraries. It would be much more appropriate to compare Express* with Rails than Node with Rails.
If you want to compare Node with something you'd be more correct comparing Node and its modules with Ruby and its gems.
* Even though, from what I can see, Express has more in common with Sinatra than Rails...
Express knows where its "opinion" ends and where it should make room for other modules with opinions of their own.
There really are two opinions at play here. Opinions of how to do something and opinions of what to do.
Express has opinions of how that differ from the http module (it even uses the http module to accomplish what it does).
Express has a minor opinion on what it should be doing and extends the what beyond the http module, but that's largely where it ends.
The problem with Rails is that it the domain of subjects it had an opinion on kept growing until it couldn't not have an opinion on stuff.
CSS versus SASS? I love Sass and used it before Rails added it. Rails didn't need to have an opinion here. Coffeescript? Same thing.
Maybe it is an unfair comparison because there's no equivalent to this much opinion about so many things in the Javascript world, except some Rails ports that people have made. And even they are seen by most as "Oh that's nice that you can get set up quickly in less than a day, but no thanks, I'd like to pick and choose what makes sense to me based on what I'm planning on building."
Had we known better maybe we would have gone with Sinatra back when we started.
Given what you've described I'd suggest you take just one more friendly unbiased look at Rails 3... and if after that it's still not your cup of tea then fair is fair. Maybe you won't choose to develop with it, but maybe you also won't choose bash it. It's pretty cool and I believe it was an attempt by Rails developers to address your very concerns. Most major components can now be easily swapped via Railties thanks to the decoupling efforts.
The architecture, like railties look pretty cool, but policy of constantly embrace and extend just leads to bloat that gets in the way when you're doing something more exotic than straight server-side CRUD.
I think this may be becoming more true everyday, but I still don't think we've come to the point where anyone has discovered The Way to do web stuff. Rails continues to introduce ideas that are interesting and important. Would CoffeeScript and Sass have received such rapid uptake if not for Rails? (Some of you may think that would be a good thing)
TDD as a cultural norm was Rails' biggest contribution. That was a good thing and was an opinion that few developers with argue with.
Maybe your experience with open-source is different. I think most contributors do it for joy, anyway.
Demanding unpaid labour has nothing to do with you or anyone else volunteering labour. My words cannot possibly be construed as saying volunteer work in open source is slavery.
"I do not believe that engineers creating software for other engineers results in exploitation."
Squeaky wheel driven development is not slavery. Users are "free" to demand features, and developers are "free" to ignore the requests. Your premise is absurd.
Similarly, cheald does not demand that users of open source projects contribute fixes for bugs. He also only stated that the exact opposite attitude is not a good idea.
Arguing either of those extremes is pointless: the discussion starts polarized and neither side will yield an inch. Introducing slavery into the discussion doesn't help.
Most authors of open source projects are interested in having their projects be used by many others. It is the usefulness to many others that provides a sense of accomplishment. If they don't pay some attention to problems those others encounter and for instance fix clear bugs in early releases, their chances of achieving that goal are lower. Observing this fact about the system is not argument in favor of slavery. There are no normative statements involved.
Similarly, if you, as a user of an open source project, want some bug fixed, the best way to go about it is often to write the code yourself and offer it for inclusion. That suggestion does not reduce them to slaves either.
To make a bazaar work, all parties involved have to be flexible in their expectations.
The number of patches that get rejected is staggering. Practice shows that 'patches welcome' is just not true.
It's beyond me why rails thinks it should dictate how to write/manage/package javascript.
As a newbie-ish javascript developer I am continually learning from great projects like requirejs, enderjs, nodejs, commonjs (AMD in general), backbonejs, etc.
How arrogant do rails programmers have to be to dip their hand into javascript best practices? Honest question, because the better I get at programming the more I feel like rails is less necessary.
Bottom line is Rails is, and always has been, and opinionated framework, which you choose to buy in to. And even in recent years they've been better about letting you opt out of certain parts of it.
The asset pipeline is not arrogance it's convenience. If you have a better system for those tasks then you shouldn't use the pipeline, but for a lot of people the asset pipeline saves time and results in a faster, better experience for their end users.
Bundling a default that doesn't play well with lots of the client-side innovations hurts rails more than helps.
The asset pipeline as it is currently designed is monolithic and an all or nothing approach.
An insistence on handling all things with Ruby is why things get bloated and stop progressing.
Sprockets solves a pain, I admit, but at the cost of adding ruby bloat to all thick client code.
Instead of being able to use javascript libraries with one another natively, everything goes through Ruby.
Anyways, I'll probably get downvoted for this comment by Railers because this is somewhat OT and trollish (I admit), but it's a legitimately complaint about the direction of Rails.
I think Rails has lost sight of what it does really well, server-side logic. Rails, in v4.0, needs to adopt a symbiotic relationship with thick-client javascript instead of trying to consume it and insert ruby in-between all the javascript parts.
For example, right now, the recommended place for a backbone.js app in a rails project is /app/assets/javascripts/. That "folder" is only going to grow as the client-side javascript becomes more important. Keeping the javascript logic "subordinate" to the Ruby elements in a Rails project causes more bloat than anything else. Look at any thick-client Rails project and count the number of gems managing javascript. If there are more than two or three, you've probably got a separation of concerns issue at the language level. That's bloat.
If you want to down vote me, go ahead. I just ask that you have the courtesy to defend your down vote with a comment. If you think I'm wrong tell me why. Maybe, I'm doing something wrong.
I have no idea what this means. how is it subordinate? The location on the filesystem?
"Look at any thick-client Rails project and count the number of gems managing javascript"
I've made a few that have no gems managing javascript. They talk to rails via REST. Rails doesn't need to care about them, and they don't need to care about rails.
If you can tell me how I can get 100% of my javascript assets managed by javascript code and still allow the use of rspec for end to end acceptance testing, I'm all ears. How do you get Rails, at one point of contact, to had off all asset recompilation, concatenation, minification, cache busting through md5 fingerprint hashing, etc. to javascript, I'm all ears.
I wanted to use require.js before. Spent a couple days working it into the project, but couldn't get it to work because of incompatibilities with sprockets. Undid everything. Someone made a require.js rails plugin, and I tried it again. It turned out to be incompatible with how the jasmine gem works and the jasmine gem is organized the way it is because that's how gems are supposed to be organized. Again, after wasting several days trying trying to get everything to work, I tore it all out again.
It's like whoever designed sprockets hasn't even considered the possibility that maybe it should permit javascript to be used freely with javascript within a Rails projects without intermediating. Near as I can tell, all the intermediation is done to be able to such things as maintaining all the files in the same directory organization (app, config, lib, vendor).
I'd split things down into something like this to cleanly separate the concerns of ruby and javascript: /client/ --/app/ --/config/ --/lib/ --/vendor/ --/spec/ /server/ --/app/ --/config/ --/lib/ --/vendor/ --/spec/ /shared/ --/stylesheets/ (if you render both static and dynamic. otherwise put this in the appropriate directory above) --/config/ --/spec/acceptance/
How do you keep all your ruby out of your javascript?
p.s. you don't have to use sprockets if it doesn't fit your needs. Your javascript can live outside of your rails app.
You can still do that, you can turn the asset pipeline off and just throw everything in /public like normal if you want.
Re: "through Ruby." If you meant that the body of the CSS file is generated for a request by running through the ruby interpreter, that's not true.