I wonder how many of the sites/web apps built with the latest crop of stacks and tool chains will be around in 10 years? I suspect these sites will either "disappear" (that is, no longer be maintained), or will be constantly updated to use the latest, greatest stack/tool chain.
The only situation where I could see this being problematic would be enterprise-type applications written on something like the Java stack or the .NET stack, where you do get tied, at least somewhat, to whatever version of the framework you are using at that time.
This is already a problem in the enterprise, has been for years. There are still companies out there stuck with VB6 code. I'm sure there are some that still have older than that laying around. Any time you get a non-compatible jump in a framework/technology you are going to get these legacy situations. Some small businesses don't have much of a choice but to scrap it and move forward with something else. The problem is that the business processes are built around this code, and in some cases the processes might be very efficient for that particular niche or market. This isn't a new problem, and it won't go away anytime soon.
I wonder why people keep picking on .net/java with this kinds of assumptions. Isn't GitHub running Rails 2.3 or something? Why just 'attack' the .net/java stacks?
I wasn't "attacking" .NET/Java stacks (I'm a .NET developer who has to maintain a .NET 2.0 code base). I was just wondering if the teams that use CoffeeScript, Node, Grunt, etc. tend to adopt bleeding edge stacks, and therefore, will have constantly evolving stacks for their products.
I also wonder if Rails is more analogous to say, the LAMP stack (I'm not directly comparing Ruby to PHP, mind you)?
As far as I know, Github also uses their own Ruby fork and have build an asset pipeline on top of their current system.
I don't think that the reason why they don't upgrade is because it's too hard. It's just that their current system works fine as is.
On the other hand, I have upgraded dozens of Rails apps from 2.3 to 3.0, from 3.0 to 3.1 and 3.2 to 4.0. Sometimes it was extremely easy, sometimes it required a little bit more effort, but I would not consider it as being difficult or painful.
My first Rails project was 2.3 -> 3.2 (with intermediary steps if I recall). It took me a couple weeks, and I ascribed most of that to how unfamiliar I was with the stack at the time. Since then, I've become rather candid in my opinion that Rails upgrades are rather trivial. Do you know of any specific red flags that would indicate a more painful upgrade process?
Well, the most difficult project I had to upgrade was a 2.3 project with a custom Asset Pipeline, with some additional features that Sprockets do not support.
Sometimes the upgrading problems arise due to gem dependencies, as a lot of gems set hard constraints on other gems' versions so it can be a little tricky to update everything at once.
All the other upgrades where rather easy, but of course it depends heavily on the size of the project, the test coverage or the underlying server infrastructure.
2.3 -> 3.0 was the worst transition. Ever since then, we've been taking steps to make upgrades even more trivial. 4.0 -> 4.1 is almost drop-in, for comparison.
First question: How is java code more tied to whatever framework it is using then javascript one?
Second question: are you sure javascript code owners will constantly refactor their old finished but functional projects to new tool chain instead letting it live while starting new projects?
The only situation where I could see this being problematic would be enterprise-type applications written on something like the Java stack or the .NET stack, where you do get tied, at least somewhat, to whatever version of the framework you are using at that time.