Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Does anybody else think there's room for a lightweight alternative to these two projects written in server side JavaScript?


Why should the language matter? Functionality should be the feature.


JavaScript is more widely accessible than Ruby or a DSL. So given that the point is all about creating recipes, the language is a defining feature.

From what I can tell both Puppet and Chef seem a little over-engineered, so I feel there's a niche for a simple (solo only) tool out there. By using something like Node it would be possible to a) run with a much smaller memory footprint b) have a more event driven architecture and c) run multiple downloads or other setup related tasks in parallel.


What javascript engine ships on a linux server today? Ruby and Python are both packaged in by default on basically everything, V8 and other javascript engines are not.

Additionally, javascript is NOT more widely accessible - if anything, learning non-DOM-manipulated javascript is INCREDIBLY painful for a beginner.

Remember, these tools are for system administration and configuration management, not for writing applications.


While javascript engines are generally not shipped with OSes these days, it's moot because chef bundles its own ruby and ignores the ancient one in the OS. I suspect that's the case with python-based packages as well. I know HP Server Automation bundles its own python. It's easier to support a consistent python version across umpteen platforms than to debug your code in all the varying versions across so many distros and distro releases. Maybe Fabric can use the OS's python, but that's about the only example I know.


Unless chef and puppet are having a hard time finding developers, I don't see how javascript being more accessible is relevant.

Your point about them being over engineered is much more interesting than you just thinking we need yet another system but in a different language. And javascript is certainly not the only way to achieve the goals you list. Just seems like an attempt to start a language war honestly.


Chef, Puppet and configuration management systems in general aren't as widely used or known as one would think. So yes, I'd argue that using a more widely accessible language is relevant.

I agree that JavaScript isn't the only way to achieve this. It's just that JavaScript is a language I like, so I thought I'd find out if there were others who shared my views. Perhaps I should have expanded more on things in my first comment. That being said, I'm pretty surprised by the negativity in the comments and downvoting.


I'm confused, are you proposing using Javascript instead of a DSL with a system like Chef or Puppet?

That's a separate issue from what the system itself is written in...

The downvoting is probably over confusion, shared by myself, about what the language used to write the system itself has to do with the merits of the system.


Chef uses Ruby for recipes, I propose using JavaScript. If the system itself was written in JavaScript, then writing recipes in it would allow for more flexibility.

(EDIT: perhaps having the ability to define recipes using a JSON only format would work as well)


There's always room to reimplement X in your favourite programming language.

It might start as a lightweight rival and yet it will continue to grow in the same trajectory as its rival eventually.

I would recommend more people to read, analyze, and understand the history and nature of software.


I think you should forward this inquiry to Ted Dziuba for consideration.


Puppet is quite lightweight, and since Puppet configs are written in a DSL, the language shouldn't matter. Please don't reinvent the wheel just because server-side JS is cool right now.


e.g., node.js + coffeescript?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: