Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Open Source Programming The Internet

Ask Slashdot: Have You Migrated To Node.js? 341

Posted by EditorDavid from the JavaScript-on-the-server dept.
A developer maintaining his company's "half-assed LAMP / WordPress stack pipeline for web and web application development" is considering something more scalable that could eventually be migrated into the cloud. Qbertino asks Slashdot: Have you moved from LAMP (PHP) to Node.js for custom product development and if so, what's your advice? What downsides of JS on the server and in Node.js have a real-world effect? Is callback hell really a thing? And what is the state of free and open-source Node products...? Is there any trend inside the Node.js camp on building a platform and CMS product that competes with the PHP camp whilst maintaining a sane architecture, or is it all just a ball of hype with a huge mess of its own growing in the background, Rails-style?
Condensing Qbertino's original submission: he wants to be able to quickly deliver "pretty, working, and half-way reliable products that make us money" -- and to build a durable pipeline. So leave your educated opinions in the comments. What did you experience moving to Node.js?
This discussion has been archived. No new comments can be posted.

Ask Slashdot: Have You Migrated To Node.js? More

Ask Slashdot: Have You Migrated To Node.js?

Comments Filter:

  • Have you migrated to qbasic? (Score:4, Insightful)

    by Anonymous Coward on Sunday May 22, 2016 @03:36PM (#52160691)

    Fuck no, it's a toy language that's being stretched way beyond its intent. JS has become the absolute bane of the internet, which now requires 2ghz machines to render ~~responsive~~ web pages, and the language has no place whatsoever on servers.

    • Re:Have you migrated to qbasic? (Score:5, Funny)

      by ShanghaiBill ( 739463 ) on Sunday May 22, 2016 @04:04PM (#52160811)

      JS has become the absolute bane of the internet

      JavaScript is a horrible language, as you can see [opentechschool.org]. But PHP is also a horrible language. If you are writing a lot of JS for the client side, then node.js has the advantage that you only need to learn one horrible language.

      • Re: (Score:2)

        by WarJolt ( 990309 )

        My experience with Node.js is that database migrations are a pain compared to Rails. Use the best language for the domain you're working in. Server side and client side design patterns are different.

      • The difference is that I can use many languages on the back end to develop web apps. I'm stuck with Javascript, a really really shitty shitty language, for anything that runs on the browser. But like many shitty pieces of technology, it gained adoption and thus continues, each iteration just as fucking terrible as the last.

        Yes, I know there are alternatives, but at the end of the day they still compile down to javascript.

        • Re:Have you migrated to qbasic? (Score:5, Informative)

          by dgatwood ( 11270 ) on Sunday May 22, 2016 @05:32PM (#52161221) Homepage Journal

          See, I don't get all the hate towards JavaScript. From what I've seen, it's a perfectly usable language except for the lack of true classes, and even that flaw can be fairly easily worked around if you're a C programmer who did OO back before it was cool (function pointers).

          What makes client-side JavaScript a nightmare is not the language, but rather the DOM, which is kind of a pain in any language. The biggest difference is that in other languages, most developers never have to deal with the DOM....

          • Re: Have you migrated to qbasic? (Score:4, Insightful)

            by ZeroWaiteState ( 3804969 ) on Sunday May 22, 2016 @05:49PM (#52161303)
            They don't like Node because it runs in a single thread and basically forces you to use async IO or risk blocking the thread which is serving incoming requests. On most frameworks you can just to kick the user request to a background thread and do your IO synchronously there. Problem is, thread per user doesn't scale for fairly high connection counts when you are IO bound (which most web apps are). However, doing async programming is hard, because the flow of control is inverted and doesn't really follow the flow of code on the page and because callbacks become hairy when you have to chain several async operations together (what happens if a call never returns, returns with exception, etc). How do you compose the results of several async operations when the results may come in our of order? JS, as a language, doesn't provide you the tools to compose those things easily. There are third party libraries which try to fix that, such as async.js, bluebird and promises API, or Rx. You have to use futures/observables/promises to compose async tasks or things get out of hand in a hurry.

          • Re: (Score:3, Insightful)

            by tomhath ( 637240 )
            People who only know one language (usually Java, or sometimes Ruby) see every other language as a threat to their livelihood. They hate Javascript, SQL, Python, PHP - everything except the only one they know. The fact is, software development languages and techniques are constantly changing; even if you don't have a need for a new language you should learn it, if for no other reason than to expand how you think.

            • Re: (Score:2)

              by jon3k ( 691256 )
              Or, alternatively, maybe javascript really isn't a great language for a number of reasons? Like, the insane equality tables. NaN literally doesn't equal NaN. Just google the truth table and behold the wonder.

              What else? Two words: global variables. If you've done any javascript, you know what I mean. Or have you ever tried to do any arithmetic in javascript [imgur.com]?

              • Re: (Score:3)

                by dave420 ( 699308 )

                How can NaN === NaN? Their only commonality is that they are both not a number. Zebras and Oranges are also not numbers - should they be equal to each other?

          • It just has the bad parts of various paradigms, yet none of the good parts. For example, some "bad" things throw an exception, whereas others just cough up an "undefined".

          • Re:Have you migrated to qbasic? (Score:5, Informative)

            by TheRaven64 ( 641858 ) on Monday May 23, 2016 @04:18AM (#52163115) Journal
            JavaScript has some nice features. It's a pure OO language, it has a simple prototype-based model with differential inheritance, but it also has a lot of ugly corner cases:
            • 'Semicolon insertion' - the semicolon is optional anywhere that the parser can determine that one should be needed. This means that some things are either code blocks or object literals depending on how you line wrap your code.
            • The only integer type is an IEEE double-precision floating point number. You can't represent a 64-bit integer without using a bignum library. Compare this with something like Smalltalk (an ancestor of JavaScript, with Self as the direct parent), where integers are either SmallInt or BigInt objects and are transparently promoted when they are no longer small enough to be hidden inside a pointer.
            • Javascript has operators that work on objects, but no operator overloading. object + string, string + number, number + array are all well-defined in JavaScript. They won't throw type exceptions, but they will produce really unexpected results.
            • The semantics of 'new' and 'this' binding are really weird. Any JavaScript function (which is actually a closure) can be either called directly or as an argument to the new operator. In the first case, the hidden 'this' parameter is the closure object. In the latter case, the 'this' argument is a new object whose prototype is set to a field in the function object. There are a few other subtleties.
            • JavaScript is a pure imperative language. The execution model is that code is run as soon as it is read, which makes quick startup difficult. V8 cheats and just does brace matching when it encounters a function and lazily parses the function when it's first called, but other languages that have a more explicit declarative structure get this for free and have cleaner entry points (there's no equivalent of 'main()' in JavaScript).

            That said, it's not significantly worse or better than most other mainstream programming languages.

        • They compile down to Javascript, but ideally that shouldn't matter any more than the fact that C++ compiles down to intermediate language in most compilers. As long as the top level language does what you want, the intermediate steps between it and CPU microcode should be irrelevant.

          I think the killer feature of Node.js is that you have the same code on client and server, which makes the mental overhead for a 'full stack developer' smaller. But now Dart, Typescript, Clojure/script, Scala, and many oth

    • Yes, we've migrated, but it doesn't run on the server. It's used to run gulp which precompiles our LESS files to CSS, minifies the CSS and JS, makes bundles out of them, and optimizes our images. I wouldn't actually run the thing on a server, but it's great as a development build chain.

    • Re: (Score:3)

      by Lumpy ( 12016 )

      It would need to if web designers would stop making webpages into flashy bling bling crap. Honestly the moment a webpage uses node,js someone should hit the webmaster with a sack of doorknobs.

      If your website takes more than 4 seconds to load on a 5mbps internet connection, then it's designed by a freaking noob that should not be allowed near a webserver.

  • It's not that bad, just don't write PHP with JS. (Score:5, Informative)

    by Anonymous Coward on Sunday May 22, 2016 @03:43PM (#52160711)

    I come from a strong C++/Java background and was drug into the Node/JS world kicking and screaming. It's still not my platform of choice but at least I don't despise it anymore. A few things:

    1. Don't try to write PHP (or C++/Java/etc) with Javascript. You see a lot of people try to force Javascript into their way of programming and that's where a lot of the callback hell comes from. It's an event driven environment, just repeat that over and over.

    2. Take the time to familiarize yourself with ES6/Promises/Rx before you start. Promises vs. Rx is almost a religious discussion but when you get down to it, both do the job. This helps a lot with callback hell.

    3. After you've chanted it's an event driven environment often enough, start chanting everything is a stream [slides.com].

    3. Use eslint religiously. This will find a lot of the mistakes new programmers make, especially ones coming from other languages.

  • The only upside of Javascript is that it is available everywhere. (and kinda functionaly-sh)
    Everything else about that language is horrible.
    I barely tolerate it inside the browser, most of the time thanks to NoScript, not even that.
    So why the hell should I start putting this nonsense on servers?
    On servers I typically use C++ if I can, Java is the clients demands it, Haskell if I feel playful (Yesod is really great), Common Lisp if I feel like experimenting (Hunchentoot is interesting), Python if I feel lazy

    • In the browser, you will have to get used to it, because it is part of the HTML5 standard.

    • Re: (Score:2, Informative)

      by Anonymous Coward

      Use a transpiler then.

      Write in a better language then compile to JavaScript / ECMAScript.

      ECMAScript is probably one of the worlds WORST languages out there.

      How about Coffee Script or TypeScript then transpile to JavaScript for deploying?

    • I was aware that the state of Javascript development is pitiful, but the recent incident where the pulling of a simple String-padding library crashed hundreds of other projects outdid even my worst fears.

      That really had little to do with JavaScript as a language and more to do with NPM, the package manager for NodeJS. I get that you'd love to hold that against JavaScript. I just think you'll have to find another reason.

    • Interesting blog about node.js here:
      http://geekforbrains.com/post/... [geekforbrains.com]
      some quotes:
      "All this to say that it feels like the Node ecosystem is constantly moving. Not in a good way. New tools that âoetrumpâ old tools seem to come out daily. Theres always a new shiny thing to replace the other. Youâ(TM)ll be surprised on how easily this happens to you and the community seems to encourage it. You use Grunt!? Everyone uses Gulp!? Wait no, use native NPM scripts!

      Packages that consist of trivial code n

  • ...no.

    But I never migrated to lhe LAMP disaster either.

    • Re:Uh... (Score:5, Funny)

      by wbr1 ( 2538558 ) on Sunday May 22, 2016 @04:03PM (#52160805)
      Yep, still running a Gopher server on AIX. The way god intended. Been looking at PERL 2, but me thinks it is the tower of Babel.

    • LAMP is not a disaster if you choose a good P. There at least two decent mainstream choices (although users of either will cast aspersions on the other). Although, upgrading the M to P won't hurt, either.

      • If "P" were "PostgreSQL", that would indeed be the case. The "A" part seems largely redundant these days, though. Between reverse caching proxies and modern HTML5 features, I'm not sure why I'd bother with it. It seems that at least Go people ditched it completely already.

  • I don't evev know what it is (Score:5, Funny)

    by Hognoxious ( 631665 ) on Sunday May 22, 2016 @03:51PM (#52160749) Homepage Journal

    Nope. Can't be arsed. Even if I could, by the time I learn it it'll be obsolete & replaced by something with a retarded name like Cunt%% or something.

    • ...by the time I learn it it'll be obsolete & replaced by something with a retarded name like Cunt%% or something.

      Jim Jeffries, is that you?

  • Much respect (Score:5, Funny)

    by twistedcubic ( 577194 ) on Sunday May 22, 2016 @03:51PM (#52160751)
    "...pretty, working, and half-way reliable products that make us money..."

    Now that's a honest business person!

  • The real question (Score:5, Insightful)

    by JustAnotherOldGuy ( 4145623 ) on Sunday May 22, 2016 @03:52PM (#52160755) Journal

    The real question is why, and what would be gained from doing so?

    This would be a major project, is the return really going to be worth the investment of time and energy?

    I think there is often a desire, rational or not, among programmers to want to redo things and make them "clean" (whatever that means) and more efficient. It's a laudable notion, but it's often outweighed by the amount of work required to re-code everything from scratch. I've rarely found it to be worth the time and effort, frankly.

    My guess is that he'd be better off optimizing some of the choke points, or perhaps implementing one of the many existing development platforms. That may require some modification, but it would still probably be a better way to go about it. It's unlikely that his needs are so out-of-band or unusual that a standardized solution wouldn't work (again, even if it required some customization).

    Wanting "Something potentially scalable and perhaps even ready for zero-fuss migration to an entirely cloud-based platform" sounds very buzz-wordy to me, and that's a red flag in my book.

    Finally, the statement that "it's about correctly building a pipeline that won't be completely outdated in 10 years" seems to be pure wishful thinking.

    Good luck with that- I doubt ANY development environment is going to survive for ten years. That's an eternity in the world of coding and development. Tools get outdated as capabilities and needs expand and mature. Hell, I doubt I'll even be using the same text editor in 10 years, let alone an entire development environment.

    • Yes but after the project fails, and he is let go, think how marketable he will be as a Full Stack Developer.

    • "an eternity in the world of coding" (Score:2, Interesting)

      by Anonymous Coward

      Code lasts a surprising amount of time compared to the mindset of the mainstream programmer. You know, the payroll stuff running on mainframes, embedded stuff running everywhere, that sort of thing. The short timespans we see on the "consumer" side, moreso on "web" and "apps" and "cloud" and other buzzwords. In fact, html5 is all about moving on from previously working stuff and "upgrading" to the latest fad. That's why it's branded a "living standard".

      Anyhow, php and mysql are rotten pieces of crap and so

    • Re: (Score:2)

      by erktrek ( 473476 )

      Local Governments with no budgets have to make their custom software last for an insane amount of time before they can get a replacement. I know of one still running Dos & a Novell 3.1 server. Web apps seem a good way to keep things standard across a variety of aging and ancient computer systems. I do not necessarily mean that NodeJS is the answer here just that using the web (internally) seems to be a longer lasting solution then a platform dependant one (say windows app). With Node at least the govt I

      • Re: (Score:2)

        by erktrek ( 473476 )

        arghh sorry "Novell 3.11"

      • just that using the web (internally) seems to be a longer lasting solution then a platform dependant one (say windows app).

        Agreed...although browsers may come and go and change, the underlying stuff will probably stand the test of time. There's no reason you couldn't build a web app that would (*SHOULD*) still work 5 or 10 years from now. But his idea of keeping everything the same for a decade is probably unrealistic.

    • The real question is why, and what would be gained from doing so?

      Given that they're currently on Wordpress, I'd think there's a good possibility they are already on the "reinvent the web wheel every few years" treadmill. So if I were talking to this guy, before I attempted to answer the question he asked I'd first ask another question - why did you move to Wordpress in the first place? Where you trying to address some existing problem(s), or was it just "hey Wordpress is popular right now so I'd like to learn it"? I suspect the latter; but, if the former was actually the

    • Re: (Score:2)

      by LWATCDR ( 28044 )

      Or look at some other CMSs.
      Node.JS is nto a replacement for Wordpress.

      • Or look at some other CMSs.
        Node.JS is nto a replacement for Wordpress.

        Yep. A modern CMS may last for quite a while, especially if they're committed to managing in house over the long haul. But it also sounds as though they have some custom dev tools that are going to be time-consuming to replace, so it might be better to fix what they can while transitioning to something that's already available rather than coding the whole thing new from the ground up.

      • Re: (Score:3)

        by Dracos ( 107777 )

        And WordPress is antiquated, poorly written garbage that survives mostly because designers live for its theming ecosystem. Anyone that has actually read that heaping plate of spaghhetti code (with its big, juicy meatballs of bad practice and thick backwards compatibility sauce) knows not to touch WP.

    • It's more than an eternity in the NodeJS world. Since the libraries and frameworks are under active development by a bunch of people that are happy to make backward compatibility breaking changes, it's likely that they'd be stuck on an archaic version indefinitely. That isn't making it future-proof, it's making development a constant task (as it is with any software that is in continuous use for a long time), except it will be more extensive than normal maintenance (which is 95+% of the time in the lifecycl

      • Re: (Score:2)

        by Junta ( 36770 )

        It's really interesting because if you look at PyPI, you'll see a lot of this too, but not universally. Some projects exercise some degree of release management discipline and multiple supported branches and such. Others are managed like you describe, just a constant stream of whimsical updates.

        Across the industry there is a very *vocal* sentiment, particularly among newcomers, that stable branches and release management in general is for the birds. We have unit tests and continuous integration now, so w

    • Re: (Score:2)

      by Junta ( 36770 )

      I think there is often a desire, rational or not, among programmers to want to redo things and make them "clean" (whatever that means) and more efficient. It's a laudable notion,

      Also, it is all too common the programmer overestimates what the quality of the redo would look like, *especially* if they are looking at redoing someone else's code. They think 'ok, this is way more convoluted than it has to be', and then realize way too late they were wrong.

      Even more so when they think part of making it 'clean' *requires* reimplementation in another language. Now there may be valid reasons to reimplement in another language (better matching your available talent pool, better performance

    • Good luck with that- I doubt ANY development environment is going to survive for ten years.

      I've been using the same dev environment (mostly) for the last twenty years. Sure, I've updated my vimrc/emacsrc, I've copied my Xresources to newer machines and I've backed up my GNUStep directory and restored on newer machines over the years.

      My workflow has remained exactly the same - edit/make/deploy[1]/test/repeat. I don't use an IDE, my 16-virtual-screen WindowMaker desktop *is* the IDE.

      [1] Deploy means anything from "push to test-server" to "program the device's flash with new firmware".

      (Yes, I know

  • Node what? (Score:4, Insightful)

    by rhysweatherley ( 193588 ) on Sunday May 22, 2016 @03:52PM (#52160759)
    I have yet to come across a problem in my career where googling it reveals Node.js as a recommended solution. Not all of us are building web apps, and frankly the web app people should probably stop and consider whether a proper application is what they really need.

    • Web applications are popular because you can deploy them instantly to all your users and they work across multiple platforms including mobile with little tweaking. Good luck doing that with a "proper" application.

    • You mean you haven't heard the app-Appy guy? He must be on vacation.

  • you have to be kidding ? (Score:4, Informative)

    by joss ( 1346 ) on Sunday May 22, 2016 @03:58PM (#52160781) Homepage

    I used node for a while, I should have known better, but it sure made a change. Not a good change, but definitely a change. I think this explains it pretty well: https://www.youtube.com/watch?... [youtube.com]

  • There are two kinds of people (Score:4, Insightful)

    by RightwingNutjob ( 1302813 ) on Sunday May 22, 2016 @03:59PM (#52160783)
    1. Those who use real programming languages.
    2. Those who are surprised when their shit breaks because someone on the other side of the internet sneezed.
  • Node.js isn't a bad environment, but I can't see much reason to move from some other web hosting technology. I suppose if the computer was maxed out with concurrent processes to serve content then perhaps the event based Node.js model might be beneficial. But if not, then it's moving for moving's sake.

    Aside from its benefits, Node.js has some substantial dangers. The whole npm model of no locking by default and fuzzy matching is a security disaster in the making.

  • what's your advice?
    Don't
    What downsides of JS on the server and in Node.js have a real-world effect?
    Scalability and lack of threads (unless you do tricksy things), lack of optimization. Sure you can throw more hardware at the issue, but if all you can pay for is a 300MB RAM, 1 core on a 1.2GHz 2nd Gen. Intel Core VPS, LAMP (or rather nginx) will easily maintain 10k hits per second for dynamic pages.
    Is callback hell really a thing?
    Yes, pure OOP in general is an issue when you need any sort of state
    And what is

  • Short answer: dont (Score:4, Interesting)

    by MyDixieWrecked ( 548719 ) on Sunday May 22, 2016 @04:31PM (#52160901) Homepage Journal

    A lot of people are spewing a lot of well-founded hate at the node platform, but the comments are missing a lot of substance.

    Node is just ok. What it is amazing at is doing lots of asynchronous IO, and has some libraries that make this pretty easy (i.e.: async). When all you need to do is read files and hit APIs and write files it's great.

    Now node has a lot of shortcomings. For one, it's really not that fast when doing actual processing. If you need to do any kind of remotely complex calculations, including things like html template rendering (handlebars), data structure transformations or even like zipping/unzipping, it's slow as a dog. And since data calculations aren't IO, async operations actually start to slow you down. AND, unless you explicitly do things in an async manner, your whole node process will lock up and only that one task will execute, which can cause all kinds of latency issues with your app.

    One can argue that ruby, etc suffer from the same fate and that's why you have multiple processes running. But because of node's async nature, if you are using a web framework like express, each process will potentially be handling multiple clients. And process that's processing will cause those clients to get slower responses and any crash will kill all of those clients.

    There is also the mess that is npm, where it becomes very easy to have a 700MB dependency directory which SUCKS to deploy to multiple servers.

    That's just my experience as a node Dev for the past 18 months.

  • Yes and it is actually harder to maintain... (Score:3, Informative)

    by undefinedreference ( 2677063 ) on Sunday May 22, 2016 @04:34PM (#52160917)

    There are more poorly-written libraries and more fragmentation in the Node.JS space than there is even in the PHP world. Beyond this, it's like developing on dev code. They've made major fundamental changes to Node in the last couple years that we've been using it that we have to almost completely rewrite our code every year or so to keep anywhere near current.

    I wouldn't change. It feels like a flash in the pan tech, it's just that developers are available for it and development is pretty rapid if they use decent front-end libraries.

    If I had it to do over again, we'd use front-end JS libraries with a more traditional server-side language that isn't like developing on quicksand where fundamental functionality changes require completely redesigning/developing your site code all the time.

  • Comment removed (Score:5, Interesting)

    by account_deleted ( 4530225 ) on Sunday May 22, 2016 @04:35PM (#52160923)
    Comment removed based on user account deletion

  • Migrated probably isn't the word. But my company has done some pilot projects from scratch in Node. There are some advantages:

    • Node is usually comparable or better in terms of performance and resource efficiency
    • Node projects seem to get to a MVP state very quickly.
    • The event-driven model is a very good solution to SOME problems.

    There are some disadvantages:

    • The number of choices you have for different stack layers can be paralyzing. Example: we had to interface with an MSSQL database. 6 different libraries

  • Conflictng requirements (Score:4, Informative)

    by lucm ( 889690 ) on Sunday May 22, 2016 @05:08PM (#52161115)

    If you want to create new web applications quickly, especially ones where you rely on a REST design, node.js is fantastic. With express js you can build things with very few lines of code, and if you respect the REST spirit you won't feel like the asynchronous thing is a problem. Just find Promise-based libraries for your database layer and you'll find the whole thing very smooth. Although I find the default templating library (jade) totally unusable, which is why I usually use swig; that's something to keep in mind if you do a lot of server-side html generation (as opposed to single page apps).

    As an added bonus, with a nginx/node combo you'll get better performance than with Apache/PHP and it's even easier to configure. (Although to be honest you could use nginx/fpm to get almost the same performance). Performance matters because it's easier to scale in a cost-effective way. You can start with a smaller host (like one of those $5 virtual machines on AWS) and provision as many of them as you need.

    Unfortunately this beautiful agility comes at a cost: node is not a stable ecosystem and unless you're extremely diligent in managing your dependencies, there's no way you can expect the same code base to live for 10 years. Just like bower and other packagers, npm is great and solves a lot of problems, but it relies on houses of cards built upon houses of cards. Libraries hat depend on librairies are more nimble but at the end of the day you will be the one left with a pile of garbage once a few building blocks start to erode. And with npm it's totally normal to have core libraries built by one guy in his basement who doesn't maintain his masterpiece; you don't see it because each "npm install" does all the magic, but really it can be nerve-wracking when something goes wrong and you start digging for weird error messages caused by cross-dependencies in two underlying libraries you didn't know you were using. At least with PHP frameworks there's usually a somewhat structured community.

    I don't pretend this is highly scientific but based on my experience, here's fhe difference between the same web application written in different programming languages:

    -Asp.net takes 25% less code than j2ee
    -PHP takes 50% less code than Asp.net
    -Node takes 75% less code than PHP

    However when it comes to long term maintenance:
    -nothing comes even close to java in terms of stability. I will happily debug a war created in 2002 and figure out ways to work around old jdk issues.
    -there is zero way to debug an Asp.net web application created with an old framework; just finding an IDE that will support it without trying to upgrade it (and failing at it) would prove nightmarish. And it keeps moving forward like this.
    -I'd rather drink a tall glass of melted butter than debug something written in PHP3, especially with the bad mixes of html, includes and mysterious variables that may or may not come from another file.
    -As for node, it's probably easier to rewrtie an app created two years ago than to try and fix it.

    Maybe things will change; PHP is becoming more mature and at some point people will get fed up with the throw-away nature of node js and some stability will appear. Until then: for quick & dirty stuff node is the best, and for long term maintenance java is king. I don't see immense value in sticking with stuff like PHP, RoR or Asp.net, but to each his own.

  • We replatformed a legacy C# app to a modern stack including Node.JS, and are very happy. The "win" wasn't so much the Node.JS language itself as that it was part of a platform that gives us fantastic code development velocity and fluidity. The "stack" includes CircleCI and Docker, MongoDB and Mongoose, Node.JS for a thin web services layer, and Angular (JavaScript) for the user experience, all integrated into HipChat for "ChatOps". Selenium and BrowserStack for end-to-end testing.

    I'll agree that JavaScript

  • David has shortened my Ask Slashdot significantly (no hurt feelings here what-so-ever), but the effort he put into his edited post is heart-warming and his preservation of the gist of my Node.js issue is spot on.

    I've noticed that the quality of the editing work done on Slashdot ever since the newest crew took over is off the charts compared to everything before and I'd like to take the occasion to give a huge warm applause to the new crew and the work these guys are doing. You folks freakin' rock and I've never felt such pride in being a long-time slashdotter as I feel right now. I wish you a nice stream of revenue and happy times as the new herald of slashdot, you guys are off to a spectacular start in my book. BRAVO!

    I'm actually going to point out to my geek buddies who've since abandoned slashdot (Whimps! :-) ) that now if ever is the time to return. Simply seeing slashdot soar to new heights is a pleasure in itself.

    As for the discussion on my question - great input, folks.
    And, btw., needs to be said after 17 years of slashdotting: You guys rock too. Of course. Naturally.

  • Javascript is going away (Score:5, Interesting)

    by phantomfive ( 622387 ) on Sunday May 22, 2016 @05:58PM (#52161345) Journal
    Javascript is approaching its peak as a programming language. The thing that will kill it is WebAssembly.

    Soon, you will be able to write front-end code in any language you like, you won't need to use Javascript. And if you're not using Javascript on the front-end, there's really no reason to use it on the back end.

  • I dove straight into Node.js to develop a platform around 3 years, I don't regret using Node.js, in fact I am glad that I used it. I essentially used the MEAN stack (MongoDB, Express, Angular and Node.js). It was great to:
    1) use JS everywhere: back-end (including the DB) and front-end.
    2) use JS: it's fun (for me) - if you use the right parts. And it performs fast enough, on par with PHP, if not faster.
    3) have an experienced community - JS and Node.js has gone through it's teething issues already.
    4) do a

  • I'm one of those older coders who started out with assembly language, did some BASIC, APL, Ridl, etc, before finding Java, then Javascript. I've seen enough PHP to scare me. I've written enough Ruby to be used to its quirks. I've been writing Javascript since 1997 and it's still my go-to language for when I need to get something done quickly and reliably. I've taken code that took 12 hours to run in Ruby and turned it into a simple Node script that ran in 6 minutes. Like Ruby and Java there is a real cult

  • Use Node for what it is good for (Score:3)

    by Carcass666 ( 539381 ) on Sunday May 22, 2016 @08:43PM (#52161967)

    Node is very good for processes that hit a database and/or file-system with "simple" manipulation. You will have to think asynchronously, and you will want to learn promises. Where it shines is when you have a lot of simple things to do during a method, and you can do those things concurrently. It's great for squeezing out every last ounce of CPU/core capacity - which can be priced at a premium if you are on "the cloud".

    For web-hosting, you can use something like Express, and implement it with clustering to scale out to your server's capacity with regard to CPUs/cores. This gets very clunky, very fast, much more so than PHP or even ASP.MVC. It seems like a solution looking for a problem. I'd avoid it.

    One of the better implementations I've seen of Node is in AWS. You can upload a Node package to their Lambda service, and trigger based upon a schedule, S3 (file) event or an inbound web call (via API gateway). It pretty much scales "auto-magically". But there are limitations. You have some utilities like Ghostscript available, but you are mostly limited to the version they have on their server images. You can include your own executables (by building them in an EC2 instance), but this increases your package size, load time, etc. If you want to use Node for a website, I'd probably limit Node's use to webservices (AJAX) for hitting the database and business logic; and drive your site's UI using a client-side engine (Angular, react, etc.). You can use it very effectively for back-end processes thumbnail generation, email notifications, etc.).

    For "quick & dirty" websites, I'd probably avoid Node, unless you are going to drink the "cloud Kool-Aid" (especially with AWS Lambda); then Node might be a fit if you are going to craft custom sites where scalability and cost management are significant considerations.

  • Node.js is neat. We have a production service running on it that handles a couple of hundred thousand messages a day sent by tens of thousands of devices. It's not much, but it's only about 700 lines of javascript. That's including comments and whitespace.

    The callback mechanism takes some getting used to. If you haven't programmed interrupt handlers or async I/O it'll be confusing, because the flow-of-control isn't really that obvious.

    Why did we choose node? Our understanding was that it's great at concurre

  • It's worth noting that Node.js has really one build manager: NPM. For why that is relevant, see this: http://www.theregister.co.uk/2... [theregister.co.uk] NPM is fairly new, and is undergoing the growing pains of becoming a major code distribution platform. Part of this is finding out why it's a bad idea to allow repositories to instantly disappear, and also why its an even worse idea for the previously used namespace to be reused by a different maintainer, especially in the absence of other security measures like code sig

  • improve instead of reinvent (Score:3)

    by Tom ( 822 ) on Monday May 23, 2016 @05:54AM (#52163335) Homepage Journal

    A developer maintaining his company's "half-assed LAMP / WordPress stack pipeline for web and web application development" is considering something more scalable that could eventually be migrated into the cloud

    How about replacing it by a less-assed LAMP stack? You know, the answer to a broken wheel is not to sit down and reinvent the wheel. Generally, it is faster, cheaper and smarter to simply get a proper wheel.

    I've refactored projects, both successfully and with failure. This is one area where the old estimate rule-of-thumb (take your best guess, double it, then increase the order of magnitude by one, i.e. replace hours by days, days by weeks, weeks by months, etc.) is so absolutely true. If you have a working pipeline, no matter how bad it works, you will dramatically underestimate the effort it takes to rebuild that pipeline on a different technology.

    Sometimes it is worth the effort. Typically, not. Replacing wordpress with something non-broken is probably ten times faster and easier than reinventing the whole thing.

Slashdot Top Deals

"God is a comedian playing to an audience too afraid to laugh." - Voltaire

Close