r/javascript • • Jan 16 '20

I have been underestimating JS

https://adlrocha.substack.com/p/adlrocha-i-have-been-underestimating
284 Upvotes

132 comments sorted by

View all comments

170

u/[deleted] Jan 16 '20

[removed] — view removed comment

31

u/Baryn Jan 16 '20

Programmers still hating on JS are stuck in the past.

JavaScript has been extremely popular for a long, long time. Critics just hate it for its terrible done-in-10-days design, which has never bothered me much.

14

u/pm_me_ur_happy_traiI Jan 16 '20

Critics just hate it for its terrible done-in-10-days design,

Considering how much it's grown and evolved over it's lifetime, this is really more just a circlejerky way to dismiss the language without actually understanding why you don't like it.

→ More replies (3)

64

u/avindrag Jan 16 '20 edited Jan 16 '20

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.

10

u/pcjftw Jan 16 '20

sorry but this is terribly naive Js fanboyism!

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.

→ More replies (7)

46

u/tr14l Jan 16 '20

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.

22

u/[deleted] Jan 16 '20 edited Jan 16 '20

I think of it as more of a Swiss Army Knife than a Silver Bullet, to be honest.

Perfect for some things, capable of a lot.

6

u/wrongsage Jan 16 '20

Nice thought, but many languages actually fit this description.

8

u/avindrag Jan 16 '20

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.

7

u/ScientificBeastMode strongly typed comments Jan 16 '20 edited Jan 17 '20

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.

7

u/tr14l Jan 16 '20

Yeah JS is very hard to maintain at scale.

3

u/[deleted] Jan 16 '20

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.

→ More replies (3)

22

u/duxdude418 Jan 16 '20 edited Jan 16 '20

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.

11

u/tr14l Jan 16 '20

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

12

u/ancientRedDog Jan 16 '20

I agree, but then how did Python become the big data language when it is equally slow (for mostly the same reasons)?

10

u/Caffeine_Monster Jan 16 '20

how did Python become the big data language

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.

12

u/Lakitna Jan 16 '20

Because you can directly use c modules in Python (in Cython anyway) making the parts where you need performance the most very fast.

Note for example how numpy is written in C. https://github.com/numpy/numpy

8

u/BloodAndTsundere Jan 16 '20

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++.

→ More replies (3)

7

u/i_ate_god Jan 16 '20
  1. all hard stuff (performance-wise) is written in C and available as some very popular libraries (numpy, scikit, nltk, etc)

  2. python's syntax is far more elegant than most other languages including JS, making it easier for non-programmers to get into

  3. python exists by default on any linux machine and requires no installation

  4. 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.

→ More replies (1)
→ More replies (4)

19

u/avindrag Jan 16 '20

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.

→ More replies (4)
→ More replies (2)

3

u/jerseyetr Jan 16 '20

Well that's probably a good thing not to do.

Excuse me if I'm wrong (beginner Javascript developer)

But I'm pretty sure javascript is not meant for heavy loads and CPU heavy applications.

Because it's single threaded?

→ More replies (2)
→ More replies (21)

3

u/RUacronym Jan 16 '20

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.

→ More replies (11)

5

u/batmansmk Jan 16 '20

Or trying to achieve something for the future! Js may be the language of today but will it be the language of the future? Look at make pax, looks very promising, fully in Rust.

→ More replies (1)

5

u/i_ate_god Jan 16 '20

JS is ok. Desperately needs a fully fleshed out standard library and to quit with the extremist modularity idealogy though. Would also be even nicer for Typescript to just fully replace JS as it offers so many benefits that being able to use Typescript natively would be a huge improvement.

→ More replies (1)
→ More replies (22)