5 ms·

Enterprise software is about long-term maintainability, compatibility, and comprehensive support for all included components. Pulling packages from npm and the

WalterSear 13y ago
A recent nodeup episode discussed how many enterprises aren't using npm packages unless they wrote them in house, because they don't want/trust any code they haven't written themselves.
- jmspring 13y ago
  I've also seen other companies who do use third party modules through npm make sure they have local copies documenting the version, source, source url, etc. Just in case a particular project disappears. One thing I wonder about, so far it seems to be mostly doing ok, but will NodeJS suffer the library versioning problems that plagued Java when I last used it...frameworks importing 2-3 different versions of Apache Commons for instance.
- mattschmulen 13y ago
  Seems like 'in general' this is a good practice. you need to know 'what's inside' if your writing bank, finance, health-care, etc ... apps on top of other peoples code. besides as a developer you want to make sure running 'npm update' does'nt change a foundation library in a negative way. the best practice in enabling this is still up for dispute.
WalterSear 13y ago
A recent nodeup episode discussed how many enterprises aren't using npm packages unless they wrote them in house, because they don't want/trust any code they haven't written themselves.
mattschmulen 13y ago
Enterprise software is about long-term maintainability, compatibility, and comprehensive support for all included components. Pulling packages from npm and the like unfortunately will not satisfy those prerequisites. That is true, historically compliance and governance has ruled enterprise IT and corporate workflow software. However its future may have priorities such as: time to market, access and cost of developer resources, flexibility and accessibility ( ubiquitous, open source, easy to learn ). javascript leads in these characteristics. Client side javascript has ruled the web, mobile implementations such as phone gap and Appcelerator's Titanium are attacking mobile. Node.js gave developers with js skills access to the server. The race is won by shipping code and a developer's skilled in javasacript are shipping products to 'market' faster with more features and less cost than other language based projects. Compatibility, maintainability, and enterprise level support will be solved by platform vendors who provide services and software 'on top of' javascript ( and its server side cousin node). Platform companies that makes it easier for js developers to introduce javascript projects into their corporate environments should look to these vendors to help them solve these problems. The future may be the best of both worlds. In full disclosure I worked with Nolan at Appcelerator and I now work for the Node javascript company StrongLoop.com, clearly I'm betting on javascript. There are lots of problems to solve and it will make for some exciting times in the years ahead.

WalterSear 13y ago

A recent nodeup episode discussed how many enterprises aren't using npm packages unless they wrote them in house, because they don't want/trust any code they haven't written themselves.

jmspring 13y ago
I've also seen other companies who do use third party modules through npm make sure they have local copies documenting the version, source, source url, etc. Just in case a particular project disappears. One thing I wonder about, so far it seems to be mostly doing ok, but will NodeJS suffer the library versioning problems that plagued Java when I last used it...frameworks importing 2-3 different versions of Apache Commons for instance.
mattschmulen 13y ago
Seems like 'in general' this is a good practice. you need to know 'what's inside' if your writing bank, finance, health-care, etc ... apps on top of other peoples code. besides as a developer you want to make sure running 'npm update' does'nt change a foundation library in a negative way. the best practice in enabling this is still up for dispute.

WalterSear 13y ago

A recent nodeup episode discussed how many enterprises aren't using npm packages unless they wrote them in house, because they don't want/trust any code they haven't written themselves.

mattschmulen 13y ago

Enterprise software is about long-term maintainability, compatibility, and comprehensive support for all included components. Pulling packages from npm and the like unfortunately will not satisfy those prerequisites. That is true, historically compliance and governance has ruled enterprise IT and corporate workflow software. However its future may have priorities such as: time to market, access and cost of developer resources, flexibility and accessibility ( ubiquitous, open source, easy to learn ). javascript leads in these characteristics. Client side javascript has ruled the web, mobile implementations such as phone gap and Appcelerator's Titanium are attacking mobile. Node.js gave developers with js skills access to the server. The race is won by shipping code and a developer's skilled in javasacript are shipping products to 'market' faster with more features and less cost than other language based projects. Compatibility, maintainability, and enterprise level support will be solved by platform vendors who provide services and software 'on top of' javascript ( and its server side cousin node). Platform companies that makes it easier for js developers to introduce javascript projects into their corporate environments should look to these vendors to help them solve these problems. The future may be the best of both worlds. In full disclosure I worked with Nolan at Appcelerator and I now work for the Node javascript company StrongLoop.com, clearly I'm betting on javascript. There are lots of problems to solve and it will make for some exciting times in the years ahead.