Hacker News Reader

Comment by davedx | Hacker News Reader

"So in a strange way, I’m happy that the messy Javascript I sometimes write tend to not last long. By nature, front-end code has a short shelf life: pages are redesigned, A/B tested and overhauled in short succession, and my painstakingly elegant carousel implementation may not have a place in the new design."

And this is why I'm scared of writing anything in node.js.

Just getting modules to work in node seemed less intuitive than C includes. Despite all the hype it felt like a step backwards, and a tool to be used only when its strengths (events/streaming) really demanded it.

I am happy to not be a front-end developer in most of my work :)

View on HN

Node modules are actually well thought out. They resolve circular dependency, and all code inside a module is confined to that namespace.

Whatever tool you take - if you start comparing with another tool that you already use, it's going to be strange and less intuitive. It's almost human nature to gravitate towards familiar things. If that's your own goal, then it's fine. But - to discount something just because it's not familiar to the way you do things is not exactly fair.

The problem with client-side Javascript code is largely a result of the horrible DOM. Once you are free of that server side Javascript looks a lot more doable.

What did you find unintuitive about Node modules? Node modules are one of the best parts of Node?

The fact that front-end javascript often changes shouldn't be a reason to avoid it as a server side language. There might be other reasons why you'd prefer something else on the server, but I don't see any connection between the two, other than they use the same language. In most projects, there's a pretty clear separation between the front-end and server.

Reply on news.ycombinator.com