3 ms·
Improve the codebase (make it small, cleaner, more easy to read, and fix issues of pastime) is NOT a wasted time. Not necessarily the BEST USE of time at a give
by mamcx 14y ago
Improve the codebase (make it small, cleaner, more easy to read, and fix issues of pastime) is NOT a wasted time. Not necessarily the BEST USE of time at a given moment, but dedicate some time to refresh the code with better tools, better syntax, better libraries, etc is a excellent way to move forward.
For a related sample, with obj-c I move to ARC ASAP, and plan to introduce the syntax literals as soon as possible. I certainly move the whole app codebase to python if exist a cheap way -and still 100% interface compatible to the coccoa-api - as like move js->coffescript for sure!
Is masochist persist in a old way just because is harder. Like when some refuse to upgrade the same language codebase to improve things (for example, I will move to LINQ, Lambdas, parallel code, async in C# as I move along) IF the change provide some advantage - reducing lines, better API, more performance, better clarity, etc -
I tough constant -but careful- refactoring of a live project is very healthy.
Is better doing it when the project is moving, that wait until a major event happend in the industry -like what happend to my competitors, still on .NET 1 / VB Classic- and suddenly, your move is damm hard, too costly, and you have no skills in the "new thing".
I certainly think something that replace or massively fix JS (including, a better JS) will be very usefull.
If is ok to move from inline styles to CSS, and from HTML to HTML5, then move from JS with issues related from years of hacking-along-design to anything else, like CS, is a good effort.
- adgar 14y ago> Improve the codebase (make it small, cleaner, more easy to read, and fix issues of pastime) is NOT a wasted time. Not necessarily the BEST USE of time at a given moment, but dedicate some time to refresh the code with better tools, better syntax, better libraries, etc is a excellent way to move forward. And as everybody has been repeatedly pointing out, switching from JavaScript to Coffeescript isn't what you're describing. Tools? The tools aren't even close to what's available for JS. Libraries? Libraries aren't even relevant since Coffeescript can call out to JS and vice-versa. Translating to Coffeescript sacrifices tooling and a codebase you know for a prettier syntax and reliance on the much smaller, much more insular community driving the language. And I'll say it: syntax is a stupid reason to abandon code you KNOW for code you're about to write. A stupid, stupid reason. Engineers need to be more mature than liking to type fewer characters for an anonymous function or because list comprehensions are 3 lines fewer than a for loop. By rewriting in coffeescript, their version history is likely trashed. They need to relearn the entire codebase. They need to develop new tools to replace the old ones they relied on, or more likely, will just live without those tools. For a prettier syntax and a couple fewer gotchas. And if a team of 3 can't avoid the common JS gotchas in their day-to-day, I certainly won't trust them to rewrite an entire codebase in a language with different semantics just to get better syntax for what already works.