LinkedIn Twitter Facebook
Lean, Kanban, Agile Pairing, TDD (sometimes test after) software architect and programmer. Worked with distributed (called cloud sometimes) computing services since 2007 using phat data (8 billion rows of data on an AVERAGE day, sometimes called big data) and everything from business intelligence to the nitty gritty of array structures inside file based data stores to create caching tiers for custom software needs. Currently pushing for distributed technologies & improving software architecture, better data centers, the best software development practices and keeping everything secure in the financial industry again. To see what I'm up to today, check out my blog at Composite Code.

8 responses to “#nodejs, why I’m basically porting EVERYTHING to it…”

  1. Kevin Dougan

    My (albeit limited) experience with it has been somewhat different:

    - “Every DB Choice” – try using SQL Server – :-) – I’ve spoken with the author of a plugin but the project is dormant now and I have yet to find a solution for this
    - Debugging is still VERY difficult – it is hard to know why problems are occurring when there are no good IDE’s available for debugging your “new framework” code
    - The resumes I see coming in weekly have less experience with Node.js than with other “more traditional” stacks
    - I find that it takes a “new mindset” to work in this type of environment, as opposed to what I have been doing previously, so that’s a curve to be navigated

    I agree with your other positive points though, but with any new technology, I always find there are trade-offs either way.

  2. Adron Hall

    SQL Server… yeah, that one is an issue. Here’s my simple fix. Wrap it with Web API Services, do simple CRUD on it and, or manage it however you’d like. If you have to have SQL Server might as well do this. Personally I’ve generally tossed SQL Server since Postgresql, Mysql, etc have all proven to be just as good or better.

    Then of course the other crux is, I’ve been primarily in a lot of the newer databases that are superior for prototyping and large data subsets used for business intelligence. This alleviates (actually requires in some situations) not using something like SQL Server.

    I’d love to hear what others are doing to wrap or fix this parity mismatch with SQL Server and RDBMSes in general. I’ve spent years dealing with RDBMSes only to finally use them in rare occasions and other systems (Document, Object, Graph, etc) much more frequently now.

    Debugging does require a strong BDD/TDD Approach to keep it under control. Traditional methods of hack code and throw it over the wall are horrible with these types of languages. Discipline is the key, otherwise things get real nasty. If you need some awesome debugging though, check out WebStorm. It’s got some pretty cool capabilities and provides an easier way for non-BDDers/TDDers to step into JavaScript Development without as much debugging pain. :)

    Resumes. I tend to hire directly from my network, resumes are a dirge and not very effective. I’d highly advise, if it is possible, to drop the traditional resume and resume + recruiter hiring practice. Grow the network, hire from the network. I promise better candidates and vastly greater returns!

    New mindset? Of course. JavaScript first off is naturally asynchronous, it is inherently a “web language” in that regard. Many others are not. The mindset is more natural to the system in which the web works. It is, indeed a “new mindset” for many, but for those just getting into the industry and they’ve only known web dev, it appears obvious to them many times. Where as the more static, synchronous languages are a broken mindset. So really it all depends on the approach and where you’re at in development.

    I started with C++ and Pascal (in years I won’t mention), so getting all the way to Node.js and getting comfortable with JavaScript hasn’t been the easiest ride, but it is absolutely worth it!

    Thanks for reading and commenting Kevin!

    …and I do agree, there are always trade-offs. Overall though, for my personal and many of my professional apps and development efforts, Node.js just gets me to the taproom sooner than most other development stacks. :)

  3. Alexey

    I usually for server-side developing use erlang.

  4. Tudor

    Unfortunately, I see very, very few web developers around that manage to use JS in an object-oriented and elegant way – most still use just global JS functions and global variables, and never heard of namespaces or how to define an object in JS, most don’t know that there are debuggers for JavaScript, or if there are or not refactoring tools for JavaScript.

    1. Adron Hall

      Tudor -> I see this too, however I rarely see much effective or elegant use of patterns or OOP in most shops anyway. Especially in enterprises. There is an extensive amount of hack and slash “get it done at all costs” type of development that is done. Which of course ends up costing an inordinate amount of money and general damage to the industry. Just because JavaScript has X abilities doesn’t mean anything more than people will mess it up just like they do so many other languages.

      At any cost… I’m OOPing it well, and determining best practices as I go. So not everybody is just hacking and slashing their projects to completion. ;)

  5. Sriram Subramanian

    Adron,

    I agree with you mostly (sorry Kevin :-)). However, i would like to highlight the sudden jump in the complexity for Node.js applications primarily due to the async nature. It is as easy as dropping a pencil to get a server running, but throw in mongo/ db, and little complex collections, you are in for steep curve!

    Having said that, I would ditch MVC3 or any older stacks completely for Node.js.

    1. Adron Hall

      Yup. My exact sentiments.

  6. node.js » Agile Mobile Developer