Slashdot Mirror
Ask Slashdot: Have You Migrated To Node.js?
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?
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?
It keeps me up at night with stress. I hate node.js and everything it stands for. It wasn't always like this though.
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.
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.
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 and just want to get the job done fast.
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.
Ditto to the Promises stuff to relieve from callback hell otherwise you'll be spending mucho time with the async module & getting that to work nicely.
If I've been to paradise, but have never been to me.
...no.
But I never migrated to lhe LAMP disaster either.
Ezekiel 23:20
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.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
"...pretty, working, and half-way reliable products that make us money..."
Now that's a honest business person!
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.
Just cruising through this digital world at 33 1/3 rpm...
Haters gonna hate, but well-written JS performs better than most php software. You could argue Javascript makes it easier to develop shitty code, but if you look at java, C and any other language for that matter, most software is shit and the one to blame is the programmer, not the language.
From shit ass slow angular websites to instant loading react ones, there just can't be a generalization. You have awesome software like Atom written in node and I bet many people would never realize it was written with Node.js.
We also have a lot of proprietary crap (look at IBM/MS stuff) written in C and now Java which are slow as a turtle. Node by itself is a fine tool and it sure does help me build better websites.
Just don't think a MEAN platform is gonna be the best for everything. I've often used node with PostgreSQL, for example, because it was a better combination for the job. The same applies for LAMP, it's not snake oil. Know your tools and use them wisely and you'll be fine with whatever path you pick.
"I decided I could write something better than everything out there in two weeks. And I was right." - Linus Torvalds
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.
Everything runs in parallel but your code? Huh? You mean, the whole thing is parallel just because underlying c/cpp libs are multithreaded? What the fuck is the benefit of that?
Rails 5.0 is about to be released. Most gems that use have a full test suite. Bundler has done away with the problems of gem dependencies long ago, come try it out again..
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?...
http://rareformnewmedia.com/
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.
I'm seeing more stories about it.
Is this something I'm supposed to just no about?
I realize it's something to do with javascript, but what is is exactly?
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.
You mentioned that your company has built their offerings on Wordpress. Because of this decision you have more maintenance needed to keep things running. The problem isn't with PHP.
Node.js has blogging packages available such as Ghost as well as numerous other packages. Callback hell is a thing and it really doesn't go away. Breakage and other issues can arise regardless.
The problem sounds more like your company is relying on others for functionality. (plugins in wordpress - you'll be trading for packages in node) If you rolled your own you'd have less maintenance needed.
No. JavaScript sucks.
"PHP is often and perhaps rightfully considered 15 years ahead of the game with stuff like Drupal, Joomla, EzPublish or WP,"
No. It is is almost never considered ahead of any game other than a quick and dirty prototype.
PHP *can* be done right of course, but it rarely is, as you concede in the next sentence (when you talk about the architecture).
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 the state of free and open-source Node products...?
There is a 'framework' for just about any solution. If you call every CMS a 'framework', it never has to be finished/useable out of the box right?
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
It's very hard to do it with classic programming in classic languages (like PHP or C), it's worse when everything is an object that has unreadable API's, different style, interwoven dependencies etc
or is it all just a ball of hype with a huge mess of its own growing in the background, Rails-style?
Isn't it always?
PHP works well because it's easy to learn and maintain, it may be easy to make really bad mistakes but it also means it's equally flexible. How many times I haven't cursed at Ruby or even Perl for 'tainting' a variable because someone deep, deep down did something funky like save state in a text file.
Custom electronics and digital signage for your business: www.evcircuits.com
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 is wordpress, of necessity since it's built on top of crap. node.js has the same problem. So you can stuff your wildly inefficient stack "in the cloud" so you can throw resources at your room-heater software with "web-scale" wild abandon. "Oh yeah, future proofing, baby!" Well, no.
Me, I make sure most of the html is of the old-and-working, not the "living (only in the latest nightly browsers)" kind, meaning I still stick to mostly html4 and css, and generate both on the pre-deployment server. Meaning most content is served statically, and can be pre-compressed. That scales wonderfully. The little dynamic stuff what's left after that, eh, we can deal with it. This is very old school, but I've yet to see the whippersnappers on the web-lawn manage to do better by throwing more code and more stack layers, even more stacks, requiring more resources, at the problem. It really doesn't matter what flavour they pick, as they keep on picking the suckiest, ickiest flavours. Like, oh, php, mysql, and node.js. Migrate from shit to crap? Maybe the other steaming heap of manure will stink less? Geeze, I don't know. Why don't you try and find out? I'm sure it'll be a worthwhile experience! Don't forget your complimentary family-sized bottle of turd polish.
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.
...spike
Ewwwwww, coconut...
You see fine fellows, there is a bigger actor at work here ---
Shitty bloated web crapplications written by 3rd world fools with 50 cent degrees are paramount to the new world order and the agenda to make us all serfs and control our every move with the cloud, IoT and big dick data.
If you write shitty software for the cloud that only means one thing --- you need more cloud!! That means more money for those that sell cloud. That means more money for those that sell hardware for those that sell cloud. This is the great silicon mindfuck!
Just think how fucking fast a bare metal web application would be. No gawdam hypervisors, no gawdamn VMs, no gawdamn interpreted scripty bytecode intermediate phantom typed gobbly gook script kiddie nonsense. You'd need far less hardware. No fucking clouds.
The agenda is --- sell, sell, sell.....depress wages, enslave workers, control population through education and media and monitor their every move with IoT and big data.
Big brother's here and his pants are down. Open wide mutherfuckers....
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 based on user account deletion
node.js is just awful. Why would anyone think that is is more scalable than the LAMP stack? It is inherently single threaded, and a total resource hog. Javascript is bad on the client side. It would be inept to even consider writing production software in it, particularly anything large and heavily structured. Also, who is going to do this work? and what limitations have become a problem with the LAMP stack? Who is going to redesign your CMS using node.js, and how will you migrate the content? Why do you think node.js will solve your problems that you haven't even bothered to specify. Do you even know why younwant to do this? Not a single worthwhile technical argument. This who speil, stinks of incompetence.
Even for client side, we only compile proper languages to javascript, these days. This lets us use sensible languages that have things like explicit declaration, sensible scoping rules, and even exotic features like an integer data type. Better to leave the technical decisions to someone who actually knows what they are doing. If you are running a web site that needs to worry about scalability issues, you should probably really be employing someone who understands these things a litle better, rather than leaving it to some inexperienced kid, who seems to have accumulated more responsibility than they should have, and has started asking joe slashdot for advice, being completely out of their depth. I know they are harsh words, but better be told now, than to go and make a mess.
Migrated probably isn't the word. But my company has done some pilot projects from scratch in Node. There are some advantages:
There are some disadvantages:
If developing something new I tend to look for ways that node can be used first, mostly because we're still trying to work out our stable development pipeline about 9 months after it started. Unless it was required I probably wouldn't choose PHP, only because the composer chain has more or less the same pitfalls of NPM, neither PHP nor node has any typing to speak of, and PHP has its rich history of inconsistency still weighing heavily upon it. to get top-notch performance out of it, you've gotta use something like HHVM which is less forgving.
Working with a legacy base, ask yourself: can this self-contained bit be written in node as a bridge to an eventual php-free-future? Does the event model make sense for the problem at hand? Will it incur unnecessary technical debt? If the answers are yes, yes and no... then develop that part in node. No reason to rebuild working PHP parts unless you actually need to rebuild them anyway.
This comment is fully compliant with RFC 527.
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.
lucm, indeed.
Seriously, if the bar is that low, then it doesn't matter what you choose. Node.js is just as suitable for making garbage websites that wow and fool and bankrupt naive clients as WordPress or any other boilerplate crap written by the type of coders who share your "money first, rapid development time second, competence never" approach to software development.
objects.
captcha: hooked, but the voice on the MP3 (I'm blind) pronounced it as hoped. It's annoying that I had to get help just to post.
I used to hate Javascript and avoided it where I could, then I decided to really learn it and now love it. Node.js is great, but for many solutions you might want to go one level higher and use Meteor.js (built on Node). There's a bit of a small learning curve to Meteor, but that time will save you much more time down the road in your project.
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 isn't my favorite language, but the tooling around it is fantastic, making development teams very productive.
The benefits of using Node.JS in the overall stack include:
- Same language for the whole stack, so a single developer can implement a whole feature (story). This eliminates the coordination cost of having three different people (front-end JavaScript, server-side C#, and database SQL) having to coordinate for use cases, giving much better velocity.
- Node/JavaScript has fantastic testing support, making it fairly easy for us to maintain 90%+ unit code coverage, and end-to-end testing of user paths. This is integrated into the CircleCI builds means that after every code commit we have a fully built, unit and end-to-end tested, and deployed (to a test environment) application.
- npm is awesome. It's a great tool, and the community support means many things are very easy.
- Mongoose is awesome.
- it's very easy to run Node.JS in AWS Lambda, which makes operations easier and is absurdly cheap to run, since you only pay for the compute you actually utilize, measured in fractions of a second. We're building one project in Lambda, and if that works well we'll likely move all the Node.JS code into Lambda, and save a lot of money at AWS.
- Yeah, event-driven programming is complex. Luckily promises make it much easier. But in return for wrapping your head around a more complex programming model, you can more scalable applications. Similar tradeoff to multi-threaded programming.
Yes, none of this is about the Node.JS language itself.
Enable 3D printed prosthetics!
Uber is moving away from nodejs https://www.infoq.com/articles/podcast-matt-ranney
The good news is, if you do this, you won't be using PHP.
The bad news is, if you do this, you'll be using Javascript.
My advice is: move to a state where assisted suicide is legal.
Regards, a Perl developer.
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.
We suffer more in our imagination than in reality. - Seneca
Have Carpenters moved over to Hammer yet? Have Plumbers checked out the newest version of Wrench? Questions like this imply that you need to use one solution to every problem, which is how we end up with broken shit like Node to begin with.
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.
"First they came for the slanderers and i said nothing."
It is badass rockstar man too!
http://saveie6.com/
There's no reason you can't write good clean flexible code in PHP. Sure, it is a bit easier in other languages, but PHP to JS is basically a lateral move in terms of language power. Anyway, if the existing code isn't good and clean and flexible it is a people problem, not a language problem. So you need to replace people, not tech stacks.
You have to be on drugs to consider javascript a worthwhile language for anything outside of the browser. The kicking and screaming was obviously because GP didn't take the drugs voluntarily.
You can use node for everything, with various degrees of success of cause.
But what makes it stand out, together with npm, is its capability as a front-stack development tool.
It enables architects to scaffold frontend projects in no time, with backend developers working in parallel on REST services.
When your frontend team is done you can easily build and deploy the frontend to any web-platform or SaaS provider.
Besides that it is useful for a lot of other tasks that you would usually program in Perl or bash scripts.
PHP7 is a huge improvement over old versions
Does it mean my webpage won't either die with no error or run fine with unhelpful warnings anymore?
I do not know why people discourage people from experimenting change! I won't recommend changing a good, existing working base from PHP to JavaScript but I'd strongly recommend using Node.js for all future deployments. While everyone is seeing callback-hell as a limitation of JavaScript, I see it an important property of JavaScript which is a kind of early warning to you if you do not modularize your code.
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 async programming - if you do it right, you tend to keep your code more modular.
What was painful:
1) Learning to write JS the "right way" and how to avoid the bad and ugly parts.
2) At the time there was no great CMS, I believe Keystone is the best at the moment, but it looks very light when compared to Wordpress.
What you need to do if you go with Node.js:
1) Learn JS well, learn "The Good, The Bad and The Ugly", such that you can avoid the Bad and Ugly. The good is actually awesome.
2) Understand prototypical inheritance, it's not your classical classes, but it a powerful and memory efficient way create objects.
3) Use a linter to write your code, like eslint, it will help you avoid the bad and ugly parts.
I still use Node.js today, but now for the Internet of Things and my embedded device runs Node.js. JS is everywhere and it's going to remain everywhere.
OP. Sorry, I forgot to use enlint.
Nope.
Nope nope nope nope.
Do not go there my friend. That way lies madness.
Any platform whose main package manager (in this case, npm) has a many-years-old bug/design deficiency wherein it requires a minimum of 2 gigs of RAM + swap space to search the package index isn't worth your time. The developers claim that they just haven't had the time to fix this, which is ridiculous, given the role that npm plays in the Node.js ecosystem. If you can't get the basics of a platform right, why would I trust the rest of it?
"This is definitely a real issue, and we're discussing how to fix it over on #6016. If we want to preserve offline search, we're going to need a better solution than reading a file containing all of the registry's metadata in a single object literal."
"@duaneking there are many potential solutions to this problem, but the current implementation suffers from the fact that npm search was designed and implemented when @isaacs more or less knew all the authors writing modules. It's always been a quick and dirty approach, and it has clearly scaled past the point where the current approach is scalable. We just haven't had time to design and implement a replacement yet."
https://github.com/npm/npm/issues/3867
https://github.com/npm/npm/issues/6016
Hi, Pick your platform based on the ability to get workers, manageability, vendor support, depth of libraries, actual business need and the overall toolchain.
The platform is just the tool. Starting with the platform is like answering the question.
"How many rooms do we actually need?" with "I have a hammer!"
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 culture of testing with Javascript and Node especially, which makes the inevitable refactoring a dream. I am thinking of kicking it all up a notch however and diving into Elixir.
I learned Coffeescript in an afternoon for a particular project (lots of Coffeescript devs) and while I do get the advantages of it, those advantages (especially with ES6) seem too slight to make me want to really deep-dive into it. I suppose I really ought to learn Swift though, as I expect it will become the new server-side hotness sooner or later.
I used to have a better sig than this, but I got tired of it
... now that it runs COBOL and FORTRAN.
that was the only showstopper holding us back!
They're more concerned with far-left ideological purity than they are about the language itself.
Twitter supports and protects racists - by smearing their critics with the "Hate Speech" label.
Hell, I'll start porting those java/tomcat applications over to it right away.
You might as well ask if we're migrating to cgi_lib.pl or CGI.pm.
I hear Ruby on Rails is good also.
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.
Gets something up and running, shows investors what it is they're potentially investing in, great for the first few iterations and low head-count startups (i.e. me and myself). But once you start gaining traction (users/money), time to pat yourself on the back, but migrate to something else. You can do this with ruby/rails, python, etc, as well.
I think what we forget as non-web devs or startup "founders" is that most of us seem to crave stability and long lasting codebases. These startups? Not so much. Build, show, fund, dismantle/decay. Over and over and over again. Why spend the time doing a proper engineering job when you've got a workforce that turns every 3 months and a startup lifetime expectancy of 1-3 years?
if you just write *good code* and don't use canned, shitty, old frameworks.
Read Evan's book on domain driven design, and code that way. You will see your projects come together quickly, and provably correct once you start using the command + domain events as your primary implementation pattern. Boundaries become clear. The correct model emerges. Dependencies and coupling melt away--making choice of toolset pluggable--then PHP or Node or Python or Java or whatever else you choose all become options that can coexist.
tl;dr;
Rather than hum and haw about what language to choose, first pick a good modelling approach (I recommend domain modelling)--which doesn't limit your tool choices at all but rather encourages patterns that make them easily interoperable throughout.
Why are we still talking about Node.js and MongoDB, oh I forgot, DevOps and the holy grail of "The Cloud".
What... A... Joke...
Actually I dislike things like java Maven and Node.js . They download tons of libraries, they are slow on my network, even different versions, over and over again. I totally lost acknowledge of whether each library is really needed, or is malware.
I like software downloaded as a zip archive, it cost my 3 minutes. but Node.js, it used 2 hours to download and fail at last, and I don't have a clue what's wrong with it.
I think you will find 200% of 0 is still 0.
Sent from my ASR33 using ASCII
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 concurrency, and this was a small and fast project to test it out. We're using it as a stepping stone to Apache Lambda, with the goal of throwing our message infrastructure into Apache at some point.
We didn't try to replace a LAMP stack with it. I suspect that would be a bad use for node...although given a low workload it could probably be done.
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... 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 signing. Putting your project under the Node umbrella means you will need to adapt as they gradually figure these things out.
Clear statements and real facts, please!
Sent as ripples into the electromagnetic field. No single photon has been harmed in the process.
I've managed a team that spent more than one day just isolating where a bug was occurring. If you don't have expert-level developers (expensive!!), be very afraid. Every once in a while a nasty bug will pop up that takes 5-10 days to finally fix. Development on large codebases is very slow due to poor modularization/code structure from the start, which I have sadly never seen done right.
If you have a greenfield situation, and really want to use node, make sure your first developer is top-notch, not only in coding skill but in coding structure. Hopefully it can be designed so that its tendencies are not to become a giant hairball -- but it still might anyway.
Me and my team migrated away from nodejs.
it is not easy to debug, ... you can't
the library versioning is shit via npm so 1 deployment may well be different from the next.
finding good libraries is like
scaling is poor.
what is it good for? quick prototyping and experimentation. Fantastic for that.
I also come from a C++ background. I actually *like* JS (or at least Coffeescript). There the main pain points are automatic type conversion (which can get you into trouble quickly), the rather strange behaviour of "this" (but you can get used to it quickly), and the poor class library. Get used to either using a transpiler (like Coffeescript) or a shim to give you the behaviour you want.
The arguments about it not being a typed language are... fair I suppose. You really do need to write unit tests, but then you should be doing that for a typed language anyway. If you want static type checking then there are a couple of transpilers that will give it to you. So I really don't see a problem.
The build system infrastructure for Node/JS is fairly immature compared to many other platforms. It's not fantastic, but not great either. Expect to spend a considerable amount of time faffing around trying to get something that works well. Part of the problem is that there are too many choices, all of which are poorly implemented and fiddly. But you can eventually get something decent.
As the parent said, callback-hell is a danger but that's just event driven programming.
My real piece of advice (if this ever gets voted up into visibility) is: don't do it unless you have (or can hire) decent JS developers. This is true of any environment, but is especially true of the JS world because there are a lot of people who graduated from "cut and paste jquery" to "systems developers". That's great if you actually learn along the way, but a surprisingly large number of people get stalled half way. I suppose this is not news to PHP developers...
TL;DR: You need to hire good people specifically for the job, but otherwise it is a decent platform to work on.
Better to wait for generators to really take off. They are showing some promise. I reached a point where I was having call back hell, looked at async, promises and decided screw that, I need some kind of new language feature to solve that. Amazingly, a year later generators came to the scene to address that which isn't too long to wait. I hate an argument with someone about promises and implemented my own promises library just to prove the point that I knew what he was talking about and that it sucked. Someone else has also gone through the same mess but unlike me could has tried everything else rather than to skip the 3 or 4 common ways to deal with callback hell until something worth actually going for arrives: http://blog.namangoel.com/deal...
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.
Assorted stuff I do sometimes: Lemuria.org
I don't know which scares me more. JavaScript in the back end or JavaScript developers.
8 months ago, when we rebuilt the previous version of our platform that was insanely in PHP (with an insane level of intricated web services) that had poor performance, we wisely choose Go.
Go is compiled. Go has strict type checking. Go has built-in support for writing unit tests.
And Go's support for concurrency is far much better than node.js (which still runs on a single CPU).
Not your typical LAMP migration here. We're moving from a C++ business tier fronted by COM classic ASP presentation tier to Node.js.
BUT some significant factors: no change to the C++ layer (other than replacing the COM interface with a Node.js native one (we have both a fine-grained native API and a web service API), and our ASPs were fortuitously written in JavaScript instead of VBScript. We have already protoyped the ability to run our ASPs unchanged in Node.js, providing a migration path of a significant code base off of a Microsoft platform with minimal refactoring.
We've actually gained on the performance side compared to the ASP interpreter (benchmarks show the Node.js native interface is also faster than .NET/C#). The underlying V8 engine is pretty good in that regard.
I do share concerns over the relatively uncoordinated pace of change in the JS ecosystem. Packages, frameworks, and the language itself are constantly changing and require frequent attention for maintenance - the MS cathedral vs the JS bazaar, but overall we are in a better position than before.
If you have the discipline to code properly and are not afraid to learn new concepts and patterns, absolutely go for it. And use Meteor!
RTFM
+ http://php.net/manual/en/langu...
+ http://php.net/manual/en/funct...
With front end development being what it is nowadays, your 'back end' that used to be 90% of your work is no longer... Stop thinking about your entire web platform as an "app" and start thinking about microservices, REST backends that just deal with auth+state+data and get your groove on. All of the fancy schtuff is happening in the browser (angular, react, etc) so contemporary web development is effectively flipped upside down from an architectural perspective.
Sure node has some great frameworks out there (loopback is awesome for this, as is hapi and a dozen others) you should probably rethink your design and implementation, not necessarily platform. If you already stocked up on PHP talent then take advantage of the frameworks available and build your service to suit (and no more aircraft carriers delivering pizza, if you know what I mean).
Regardless of your chosen platforms, you can find decent REST service frameworks that let you get your focus back in the browser/app/client where it should be.
One thing I'll give Node is that it is dead simple to deploy (perhaps too simple for some!) so the tooling available is pretty good.
...didn't go so well for us. We dumped Node.js and moved back to PHP after a lot of reliability problems with Node.js. Perhaps they're fixed now. Perhaps not. Either way that failure seems to have (unfortunately) locked us into PHP for the foreseeable future. Too bad. I'm no fan of JS, but it sure beats PHP. Sigh.
You don't implement error-handling and then you blame PHP?
There's actually not a lot in Ruby that you can't modify at runtime. You can't break variable assignment, and I don't think you can erase the concept of class inheritance, but most other components are up for grabs. It's perhaps not quite as flexible as Lisp or Smalltalk, but there's definitely no shortage of hanging rope. Metaprogramming Ruby was an enlightening look at how this can be put to practical use. Personally, I think that "monkey patching" is grounds for "developer punching", but there are a great many tools which improperly used make superlative footguns.
Those who advocate genocide deserve every protection afforded by law, and none afforded by common human decency.
we built a new product in node; I was very optimistic going into the project and looked forward to the new experience, working with node was the most painful, least pleasant software development experience I have ever had to suffer through
I am playing with Three.js on a personal project, and in order to make the server component, I will probably use Node.js.
I am also watching what APIs other projects use. One trend I have seen is people using npm/Webverify/Beefy chains of packages that pull the most recent code every time you reload the webpage. Not sure I can get into that. I want to make sure everything works, and only have a product I know will work each time (unless servers go down for some reason).
Complete rubbish; object based & functional, not OO.
Functional languages are ones that have a strong notion of a pure function (i.e. something that is side-effect free and has immutable state). JavaScript doesn't come close to representing this.
A very good definition for the term: rubbish language.
Name one mainstream language that doesn't have odd corner cases.
by definition not an integer.
Sorry, I meant the only type that you can use for representing integer data. You effectively have a 53-bit integer that silently becomes a floating point value on overflow. This is the type that you must use for all integer data, including things like loop induction variables.
I am TheRaven on Soylent News
I swear to christ if anyone who is within physical reach of me utters the words, "migrate to the cloud", I'm punching them in the fucking face.
I can't speak for javascript's good or bad performance and usability in complex projects but I can say that Node.js and simplecart which uses Node.js is very easy and runs fine. Yeah a hacker can change a price going to Paypal with it but with only one product to sell it is easy to see if the correct price is being transmitted. A little html and boom the site can run on a Raspberry Pi and perform well.
JS ES5 is awful but ES6/7 is quite nice syntactically. Throw in libraries like React and you have a very pleasant client side dev experience. But asking about switching to node is already a dated question. People who already switched to node are asking if they should switch to serverless via static hosting and microservices such as (but not limited to) AWS Lambda (Python would be my language choice there).
(That, and people modbombing me only serves to confirm it)
Twitter supports and protects racists - by smearing their critics with the "Hate Speech" label.
This is so braindead. Whoever thought this out must be sick.
I wanted to install some software to control my cromecast.
First install: the nodejs in the repository is too old.
oh well, just upgrade my linux, it's kinda old...
Next install: the nodejs in the repository is too new!
WTF? And of course the "too new" message is displayed via 500 lines of error stack dump.
Well this is exactly how you get people to embrace and use nodejs, NOT!
Atari rules... ermm... ruled.
Server side and client side design patterns are different.
But sometimes you want the prevalidation logic on the client to have the same behavior as the authoritative validation logic on the server. There are two common ways to keep the logic in sync without violating Don't Repeat Yourself: either write the server in the client-side language or transpile the logic from the server-side language to the client-side language.
Strings are also unicode by default which sucks on backend.
What about Unicode in general necessarily "sucks on backend"? Or are you confusing Unicode with its UTF-16 binary form, which arguably does suck compared to UTF-8?
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.
Converting from bits to bytes and subtracting protocol overhead produces a limit around 2 MB, even if a site keeps its scripts under, say, 10 kB. If a single document has more than 2 MB of illustrations and photos, such as a long how-to article, how should it be sent? Should all images after the first 2 MB use "lazy loading", where an image doesn't load until the user has scrolled to it and thus can't be viewed without turning scripts on for the site or after going offline?
I just thought of a passive-aggressive way for a design firm to fight clients that demand excessive scripted animation.
1. Clarify to the client that some design firms also run websites offering reviews of random sites' usability. Name-drop "Web Pages That Suck", "Tab Closed Didn't Read", and "Plain Text Offenders".
2. Remind the client that disability discrimination laws may apply. Name-drop National Federation of the Blind v. Target Corp.
3. Provide a view of the same information with a similar look but less bling, and link to it from the main site with a wheelchair symbol (alt="Accessible version of this page"). Follow best practices for accessibility and usability on this view.
4. To disguise this site's connection to the design firm, use a shell company and/or review other firms' sites.
5. If a client insists on bling that harms the user experience, and particularly if the client requests removal of the accessible version, review the site and mention the harmful UX and possibility for lawsuits from an advocate for the disabled.
Now there may be valid reasons to reimplement in another language (better matching your available talent pool, better performance, you would just prefer it)
Especially when the deployment platform dictates the choice of language. Examples include Xbox Live Indie Games and Windows Phone 7 requiring verifiably type-safe CIL for the .NET Compact Framework (in practice, requiring C#), or the web requiring either ECMAScript 5 or a language that transpiles to ECMAScript 5. Then "better matching your available talent pool" means "we would have to hire someone to write a transpiler to the only supported language", and "better performance" means "the alternative is writing an interpreter".
but if it's just to 'make it clean', that can pretty much always be accomplished within the existing language choice.
Even if "the existing language choice" is assembly language, as in the case of porting a classic video game to a modern platform? Can assembly language be made as clean as, say, Python?
You just need to pick the right combination of frameworks and programming language. Everything can be converted to everything else nowadays.
Unless the web application is a workaround for a platform owner's policy that specifically forbids a set of native apps. For example, applications doing any of these things cannot be converted to a native iOS application intended for distribution to the public.
No.
Next question?
I started on Perl to maintain existing code, but have since used it extensively for everything I do these days. The greatest thing about perl is the wealth of CPAN libraries available. Recently I was asked to automate the process of logging into a mailbox, downloading the most recent message meeting various criteria, extracting a zip file attachment from it, extracting an Excel ('97 format) file from the zip file, and importing its table of data into the database used by a large webapp.
Thanks to CPAN, I had the whole thing done in less than a day. CPAN modules are a mixed bag, but most of the important ones have decent documentation and a lot of real-world testing. They're also trivial to install. "cpanm ModuleName".
I judge web frameworks by how *little* they try to do for me, and how easy it is to pull in other modules that serve specific purposes. The Perl ecosystem excels at this, more than any other language I've worked with.
Mark of the Coder fades from you. You perform Opening on World of Warcraft. Warcraft crits GPA for 4. GPA dies.
Does it mean my webpage won't either die with no error or run fine with unhelpful warnings anymore?
If you want exception semantics instead of "error reporting", use ErrorException .
PHP7 is a huge improvement over old versions. If you haven't looked at it, do so. PHP sucks in 2016 is mostly FUD now.
To see how much of an improvement PHP 7 is, let's check the 7 things wrong with PHP 5 that I mentioned in this article (and previously in a Slashdot comment):
Things such as switch use the byzantine semantics of operator == Not fixed to my knowledge. Parse errors and undefined functions are fatal PHP 7 makes them "engine exceptions" which are catchable Error instances. Inconsistent naming and argument order conventions for standard library functions Not fixed completely for back-compat reasons, but PHP 7 has started to drop some duplicate functionality. Backwards associativity for operator ?: Not fixed for back-compat reasons, but at least the new null coalesce operator ?? has its associativity on the more useful side. Letting the server operator change program semantics in annoying ways Safe mode and magic quotes were already gone in PHP 5.4. cURL would not follow redirects if open_basedir was set until September 2013. But upload_max_filesize still defaults to 2MB, which I see as unnecessarily small. Semantics breakage in minor (5.x) versions encouraging shared hosting operators to delay making new versions available to subscribers Not fixed until the majority of shared hosts offer PHP 7. Has someone run a survey about this? No keyword arguments Not fixed.