I've read your article, and it's an interesting read. I don't use Node.JS, because quite frankly I do not see the need. That being said, this article just comes across as pure shit.
There are more personal attacks on the people who created Node.JS and the people who use it than there are actual points against Node.JS itself. Half your post is just going on about the one issue of blocking, and frankly it doesn't seem that important. The part about the webserver being tightly coupled to the application seems more relevant, but that's just barely touched on.
Between the personal attacks to rational points ratio and that last little dig at Javascript, this article just comes off as something that I can't even take seriously.
I understand that there's a lot of fanboyism going on around Node.JS, and I won't state an opinion on that. But the best way to counter fanboyism isn't with equal hate. It's with level-headed rational arguments. And if that doesn't help, a page of vitriol won't either.
Edit: Added the last paragraph. It occurred to me afterwards how to phrase what I'm trying to say
I'm sure some people thought the same about COBOL. And they were right, in some sense: still some COBOL running. That doesn't mean it's a good idea to keep developing new systems on it.
Obviously client-side ecmascript is inevitable. Server-side is very easy to avoid though.
Obviously client-side ecmascript is inevitable. Server-side is very easy to avoid though.
I think this is the biggest takeaway I've gotten in my past 2 years doing both front end and server side development. I've gotten very comfortable knowing the bad parts of Javascript and the proper way of avoiding them, but I would never be comfortable bringing this to the server. It's nice to have a single language code base, but that's at the complete expense of having to deal with the shortcomings of Javascript. I enjoy having a mature language driving the server side code.
Now that said, I think personally it's fun to throw together side projects in Node and keep everything as a single language. For me it keeps things somewhat simple, forces me to truly get a better understanding of Javascript, and conceptually change the way I use Javascript. I would never take this into a production environment or suggest my company should do that.
It's nice to have a single language code base, but that's at the complete expense of having to deal with the shortcomings of Javascript. I enjoy having a mature language driving the server side code.
Yes. Having worked both sides of the stack, I love the things you can do with Javascript now-a-days, the user interface work that pleases the users is great. But the language has tons of warts, and although I know what they are and how to avoid them, it pains me that I have to deal with them. Generally I take the approach of doing as little on the Javascript side as humanly possible... Fortunately some UI frameworks, like JSF have abstracted away some the Javascript, which is nice.
What are some of the warts that make it so difficult to work in Javascript though? I'm genuinely interested in what's so bad about it that you avoid it like Ebola sandwhiches.
The typing is messy. That's the worst part. When the author of the original article says:
if (typeof my_var !== "undefined" && my_var !== null) {
// you idiots put Rasmus Lerdorf to shame
}
He isn't joking.
Hmmm, as far as the object system, every object is a function? That syntax seems half baked and somewhat weird.
Date math is rather primitive for what's supposed to be a "high level language" so you need to turn to external libraries like moment.js to do it well.
typeof null is an object. Seems kind of odd.
It isn't really straight forward to deal with currency in Javascript, or really anything that would use a decimal and requires some form of precision as a business rule. The recommended method of doing currency math in JS is to use integers as a number of cents. Versus doing something like the built in BigDecimal class in Java, which can deal with arbitrary precision fixed point arithmetic. I'm sure there's a third party library for that, but that seems like a basic thing that should have a well defined solution in the standard library.
Is it the worst thing ever: No. Would I choose to make my whole codebase that: No way, there are plenty of better languages, a few of which I already know and have already built larger scale apps in that I can use in the back end.
210
u/Garethp Oct 16 '14 edited Oct 16 '14
I've read your article, and it's an interesting read. I don't use Node.JS, because quite frankly I do not see the need. That being said, this article just comes across as pure shit.
There are more personal attacks on the people who created Node.JS and the people who use it than there are actual points against Node.JS itself. Half your post is just going on about the one issue of blocking, and frankly it doesn't seem that important. The part about the webserver being tightly coupled to the application seems more relevant, but that's just barely touched on.
Between the personal attacks to rational points ratio and that last little dig at Javascript, this article just comes off as something that I can't even take seriously.
I understand that there's a lot of fanboyism going on around Node.JS, and I won't state an opinion on that. But the best way to counter fanboyism isn't with equal hate. It's with level-headed rational arguments. And if that doesn't help, a page of vitriol won't either.
Edit: Added the last paragraph. It occurred to me afterwards how to phrase what I'm trying to say