5 ms·

That's so cool! Actually, it also highlights one of the things that concerns me about the proliferation of build tools, frameworks, and transpilers etc in the w

That's so cool! Actually, it also highlights one of the things that concerns me about the proliferation of build tools, frameworks, and transpilers etc in the web sphere at the moment. The other day I was able to run and start modifying a "DHTML" side-scrolling shooter game I wrote in 2004 by double clicking the index.html file. To run games I'm making now, I have to have the correct versions of Grunt, and all the related dependencies - working CoffeeScript converters etc. In 2024 it's going to be tough to set up a working environment to modify and run 10-year-old code: certainly a lot harder than just double-clicking an html file.

bmj 13y ago
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.
- BSousa 13y ago
  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?
  - iagooar 13y ago
    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.
    - Arnor 13y ago
      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?
      - iagooar 13y ago
        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.
      - steveklabnik 13y ago
        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.
  - bmj 13y ago
    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)?
  - steveklabnik 13y ago
    dotcom is running 2.3, but my understanding (I don't work at GitHub) is that they're very, very SOA, and use quite a bit of Sinatra.
- bkmartin 13y ago
  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.
- watwut 13y ago
  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?
deleted 13y ago
[deleted]
72deluxe 13y ago
That is a very good point. The years of web progress has just been new ways to get a result from a server. Repeated again and again, and renamed each time!
reidrac 13y ago
You're lucky, I wrote a "DHTML" game in 1998 and it won't work today (although I didn't do anything fancy, just DOM manipulation). I was thinking about exactly that a couple of days ago trying some WebGL. The web is a moving target and you're not guaranteed that anything advanced today will last :( On the other hand I wrote a shoot'em up in C and SDL in 2003 and still compiles and works as well as it did back then.
- phillmv 13y ago
  Yeah but comparing C/SDL to JS/WebGL is unfair in terms of maturity of the platform. JS will soon be 20 years old, but in terms of a language community, outside of jQuery plugins it's only ~5 years old. You're not wrong, though. I can only imagine the nightmare of finding copies of all the library dependencies will be five or ten years down the road ("oh this needs jquery 1.9 but we're at jquery 5 now, and what was underscore?") not to mention the actual execution environments ("Works best in 20 versions of Chrome ago"). The web at least is a tractable problem. Did you ever have a game that you really liked that only worked in iOS 4? Tough shit.
  - reidrac 13y ago
    C and SDL have changed in the last +10 years, but the old stuff still works. I invested a lot of time into getting autotools right and it looks like it really paid off :) I don't know why the web is different, but it is, and it makes using the newest stuff a little bit uncertain.
    - mnx 13y ago
      I think the web is different because of how easy it is to roll out new features - most of the new stuff only is guaranteed to work on browsers up to a couple months old, but that's enough since people update often.
golergka 13y ago
I think has to do with the complexity of the software you're working on. The games you're working on right now are likely much more complex that 2004 html game. And as someone who recently tried to get the original Doom source code to run (still unsuccessfully), this is just as true for older code.

bmj 13y ago

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.

BSousa 13y ago
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?
- iagooar 13y ago
  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.
  - Arnor 13y ago
    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?
    - iagooar 13y ago
      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.
    - steveklabnik 13y ago
      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.
- bmj 13y ago
  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)?
- steveklabnik 13y ago
  dotcom is running 2.3, but my understanding (I don't work at GitHub) is that they're very, very SOA, and use quite a bit of Sinatra.
bkmartin 13y ago
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.
watwut 13y ago
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?

deleted 13y ago

[deleted]

72deluxe 13y ago

That is a very good point. The years of web progress has just been new ways to get a result from a server. Repeated again and again, and renamed each time!

reidrac 13y ago

You're lucky, I wrote a "DHTML" game in 1998 and it won't work today (although I didn't do anything fancy, just DOM manipulation). I was thinking about exactly that a couple of days ago trying some WebGL. The web is a moving target and you're not guaranteed that anything advanced today will last :( On the other hand I wrote a shoot'em up in C and SDL in 2003 and still compiles and works as well as it did back then.

phillmv 13y ago
Yeah but comparing C/SDL to JS/WebGL is unfair in terms of maturity of the platform. JS will soon be 20 years old, but in terms of a language community, outside of jQuery plugins it's only ~5 years old. You're not wrong, though. I can only imagine the nightmare of finding copies of all the library dependencies will be five or ten years down the road ("oh this needs jquery 1.9 but we're at jquery 5 now, and what was underscore?") not to mention the actual execution environments ("Works best in 20 versions of Chrome ago"). The web at least is a tractable problem. Did you ever have a game that you really liked that only worked in iOS 4? Tough shit.
- reidrac 13y ago
  C and SDL have changed in the last +10 years, but the old stuff still works. I invested a lot of time into getting autotools right and it looks like it really paid off :) I don't know why the web is different, but it is, and it makes using the newest stuff a little bit uncertain.
  - mnx 13y ago
    I think the web is different because of how easy it is to roll out new features - most of the new stuff only is guaranteed to work on browsers up to a couple months old, but that's enough since people update often.

golergka 13y ago

I think has to do with the complexity of the software you're working on. The games you're working on right now are likely much more complex that 2004 html game. And as someone who recently tried to get the original Doom source code to run (still unsuccessfully), this is just as true for older code.