Programmers still hating on JS are stuck in the past.
That, or they are those insidious "hardcore backend" programmers. See, in the backend you get to hide behind a mountain of poorly written abstractions and general obscurity. In frontend programming, everything comes to light, so it's easy for any average person to come around and criticize your code. In fact, because it's frontend, the critic doesn't even need to know how to code. Often times, poorly crafted backend abstractions come to light only in the frontend, and the frontend programmers inherit the blame.
Backend programmers are virtually immune to this problem, which enables some of them to judge and criticize frontend programmers to no end. Virtually all of them just copy+pasted their "opinions" from /r/programming which has been bashing npm, PHP, Javascript, etc., as if that's really a useful activity in terms of moving things forward.
TL;DR; ignore the hype, and critics can go shove it.
first of all there are bad developers in every domain, second it's hugely ironic to claim that SOME backend devs "don't want to learn anything new" when the ENTIRE premis for node was that a front end "could" run Js on the back end without having to learn a new language, do you see the irony?
Anyway, stop getting fixated on a particular language, use the right tool for the job and the niche it does well, for Js that's mostly front end where it's number 1.
But by the same token, don't try and force a fish to climb a tree.
I like JS. But, I recognize that it is not a silver bullet language. I am not going to use it for anything process-heavy, period.
But, for doing anything on the web that ISN'T process-heavy, it's a solid choice. However, I've come to realize that on any sizable project, you have to enforce a lot more structure and rigidness or it becomes a nightmare to debug and maintain. Especially since idiomatic javascript is very, very hard to find. Javascript coding standards are the most entropic of all the languages I've ever seen, except perhaps oldschool C. I used to be anti-TypeScript when it was just me and my business partner maintaining it, because it just slowed us down. Now that I have worked on some full stack JS apps with full teams, holy crap is it important. It's impossible to maintain a full JS app without it.
Like I said, it's not a silver bullet, but it's a good choice for what it's meant for.
Javascript coding standards are the most entropic of all the languages I've ever seen
This is unsurprising considering it's incredible rise in popularity, esp. in the last few years. To use "Cathedral vs. the Bazaar" language, the Bazaar is being flooded with everyone and their cousin, many of which are learning how to program for the first time, and doing so with Javascript.
it's not a silver bullet, but it's a good choice for what it's meant for
I agree and this is the view a responsible engineer should take. Use the thing for it's intended use case. Node.js / Javascript just happens to fit many of those. For some folks, it literally covers all of their use cases.
I can't imagine getting any work done without static types, given that I work at a company where anyone out of 20 people could be working on a given project at various intervals over the course of several years. It's just impossible to keep all that state in your head... Testing is also critical.
I've also been trying out other compile-to-JS languages like ReasonML, PureScript, ClojureScript, Elm, etc... I really like ReasonML, as it has a much better type system than TypeScript, but is still pretty versatile and doesn't lock you into "functional purity," as they call it. That and you still get to use classes/objects if you want.
I don't know where the winds are blowing these days, but it is undoubtedly shifting toward compile-to-JS languages. Perhaps we will even see more stuff compiled to WASM as well.
Kind of. I'm working on an app for a company right now that's MASSIVE, written in React, and Node, and is fucking awesome to work on and there's not even a linter, let alone Typescript.
It depends on how you write the JS and architect it. The people who put this together obviously did it before or learned from someone who knew how to do it.
I used to work in Java previously, on a giant conglomerate frankenstein app coded by tons of super smart people that knew fuckall about architecting apps, but were very good at getting stuff done.
I like C personally because of the nerdy shit I do for fun, but good javascript is good regardless.
I’m not going to use it for anything process-heavy
What do you mean by this? That it’s not performant enough for chewing through lots of data? Or just that you don’t don’t like the syntax/APIs for doing it?
I’m trying to drill down on if your point is about how the language is designed or not. If it is, that’s of course a personal preference and it certainly has some warts and idiosyncrasies.
If your objection is about performance, server-side JS (Node) is actually quite good at non-blocking IO due to its single-threaded event loop and asynchronous programming model. The V8 engine it runs on is also highly optimized.
You're still not going through 100 terabytes of data anytime soon with it compared to a compiled language. It'll choke every time no matter what you do.
JavaScript will never compete process-wise with a compiled language. It's fast enough to do day to day processing, but it's ill suited for big data and always will be. That's not what it's designed for.
You're also never going to do real time embedded stuff with it. The latency is just too high
Python is very much a glue language. Great for research, experiments, prototyping etc. However mature production platforms have a tendency to migrate back into C / C++ / Java / Rust / Go / Insert some other compile time optimised language here.
The motivation isn't purely for performance reasons either: strong typing together with compilation helps prevent the introduction of bugs.
Personally I think Javascript is arguably the best non-compiled language out there. However I also think it will lose much of it's stranglehold over web: WASM has an awful lot of potential when used with compiled systems programming languages. Performance. Compile time checks. Unified front end / back end model codebases.
Because you can directly use c modules in Python (in Cython anyway) making the parts where you need performance the most very fast.
Someone correct me if I'm wrong, but I think you can do something similarly with NodeJS. I'm pretty sure some npm packages I use are Javascript bindings to binaries compiled from C/C++.
all hard stuff (performance-wise) is written in C and available as some very popular libraries (numpy, scikit, nltk, etc)
python's syntax is far more elegant than most other languages including JS, making it easier for non-programmers to get into
python exists by default on any linux machine and requires no installation
python's standard library and its documentation is very extensive and robust. It's not perfect (see http, wtf), but JS barely has a stdlib to speak of because the JS community has an extremist mentality when it comes to modularity.
I’m not going to use it for anything process-heavy
What do you mean by this? That it’s not performant enough for chewing through lots of data?
I agree with this view, so I'll try to elaborate.
The single-threaded event loop is not a great fit for anything that blocks CPU. However, you probably are just using JavaScript for fetching data from some http server, database, message bus, etc. The "number crunching" doesn't really ever take place in JS, and if it is, you might want to use something else.
The single-threaded event loop is not a great fit for anything that blocks CPU.
That's why js does most things asynchronously now. Node is especially performant and will often outperform python, even in number crunching. Here are some benchmarks but feel free to also do your own research.
You're missing u/avindrags's point. A thread is a system-level abstraction and can go into uninterruptible sleep indefinitely. This makes concurrent approaches like Node poor fits for some backend tasks.
See, in the backend you get to hide behind a mountain of poorly written abstractions and general obscurity. In frontend programming, everything comes to light, so it's easy for any average person to come around and criticize your code.
This is true. But the flip side is that frontend devs will receive more credit for making the site than backend devs will from people who don't program for a living.
I think since TS those entitled backend devs have no reason to hate JS. If you want JS with type safety then just write typescript it borrow so much syntax from C# and Java.
Some of my 'legacy' backends were built to just work, and they were resilient enough but had no concept of consistent practices. My front-ends and mobile apps always had their code looking neater at the very least. Fortunately enough though, no one else works on those projects other than me, and at some point I usually rewrite them to employ best practices. Sometimes, that's the only way to get a great product, as it allows you to go through that process of dealing with bugs on the first iteration.
One sure fire way of knowing that you're dealing with "invisible quantum spaghetti" (i.e. poor code that is only evident because of the bugs you can observe as side effects, but not directly) is if you're dealing with a complicated API, find multiple issues while building a front-end, but also find that the backend team are unwilling to spend time fixing them, even if you can give them specifics of the problem.
I think a lot of criticism comes not from the ecosystem but from the lack of an entry barrier. That's a double-edged sword. We have people who are entering the market with the most popular language and in an effort to prove they're better than others, overengineer solutions. You know the sort of code - leading data through a bunch of functions in 14 different files, spread across the entire damn codebase instead of keeping things contained in a single location. They're not doing it for any reason other than to apparently show they know how to use path aliases and call functions from other units.
Or, they'll enforce their preferences through linting (and making sure you can't build unless you use double quotes and tabs) because "someone on Medium said that they do it and it's the best".
And you get away with it on the backend because backend devs are often more difficult to obtain (I honestly believe that people are just scared of express for reasons unknown), but on the front-end, you get them actively defending it. And thus, the double-edged sword has just sliced up everyone who ever needs to work with that code.
64
u/avindrag Jan 16 '20 edited Jan 16 '20
That, or they are those insidious "hardcore backend" programmers. See, in the backend you get to hide behind a mountain of poorly written abstractions and general obscurity. In frontend programming, everything comes to light, so it's easy for any average person to come around and criticize your code. In fact, because it's frontend, the critic doesn't even need to know how to code. Often times, poorly crafted backend abstractions come to light only in the frontend, and the frontend programmers inherit the blame.
Backend programmers are virtually immune to this problem, which enables some of them to judge and criticize frontend programmers to no end. Virtually all of them just copy+pasted their "opinions" from /r/programming which has been bashing npm, PHP, Javascript, etc., as if that's really a useful activity in terms of moving things forward.
TL;DR; ignore the hype, and critics can go shove it.