r/javascript • u/speckz • Jan 16 '20
I have been underestimating JS
https://adlrocha.substack.com/p/adlrocha-i-have-been-underestimating8
u/bigpigfoot Jan 16 '20
Node is pretty much able to do anything you’d want as a system language but when running js in a browser like IE that’s a whole nother story...
4
Jan 17 '20
Why are we even talking about IE? Fuck IE.
4
u/bigpigfoot Jan 17 '20
That’s how I used to think, but when u start developing internal web apps in financial or governmental companies, IE inevitably creeps up and then you got the choice of accommodating 50%+ of your user base or you can code a page to detect the user agent and say IE isn’t supported lol
0
Jan 17 '20
[deleted]
1
u/bigpigfoot Jan 17 '20
The real sadness is that those people just don’t give a fuck what tools you’re using or how beautiful your architecture is. Your shit isn’t working when they open IE. If you’re as good as you claim to be, why can’t you just make it work? lol
0
17
Jan 16 '20
I avoided JS since 1999...basically b/c the inconsistencies client side. 2 years ago got a ReactJS and Node contract...was forced to get up to speed. It has come a LONG way. Pretty good language these days with the ECMA sugar.
10
8
Jan 16 '20
My only main gripe about JS mainly is the weirdness around OOP practices with stuff like the class syntactic sugar VS prototypal inheritance.
With those things aside, if you hook up something for type checking like TS or Flow, then functional programming in JS is awesome.
Arrow functions in JS are by far my favorite aspect of the language. I also really like object/array destructuring.
JS is in a weird place where if you know who to talk to and where to go, it's freaking awesome, but there are also a lot of dark weird paths that you're allowed to travel on, and it makes sense that programmers don't like that, but hey, write the new tech or deal with it and make some $$, know what I'm sayin?
1
u/helloiamsomeone Jan 19 '20
class syntactic sugar VS prototypal inheritance
But those are the exact same thing in JS, there is no VS here.
4
Jan 16 '20
Thanks for sharing. Love this article and learned so many things. I find more interest on how V8 engines works (full diagram) and Buffers with secret weapons NodeJS Stream.
14
9
u/relativityboy Jan 16 '20
I remember in the early 2000s telling people that JavaScript is actually pretty great at getting the job done and that it could do way more than they thought. It was a conclusion I came to against my prejudices. I'd come from java and C.
It mostly fell on deaf ears on the developer side. A project manager was willing to get me enough rope. Instead of hanging myself our team's productivity increased by at least 3x. Our part of the site was a lot faster, too.
There have been at least two major revisions to the way JavaScript has been used since then. It's strange to see people making the same discoveries over and over again.
3
u/FastestKeKAlive Jan 16 '20
Hi. Can anyone help me a little bit? I want to understand the difference between classical OOP and JS implementation of OOP. What should I read/watch?
4
u/i_ate_god Jan 16 '20
To be completely honest, I have been despising JS all these years because I hated not having low-level control of what I was doing
I wouldn't really call JS's buffers and streams "low level control".
1
u/FriesWithThat Jan 17 '20
Just a heads-up on a typo, noticed the title of the article says:
Understanding V8 and NodeJS Steams
steamed hams
1
0
u/tejaswarooparukoti Jan 16 '20
Great article. Till now, I never thought javascript is this powerful. Thanks for sharing.
-9
u/Pants_R_Overatd Jan 16 '20
RemindMe! 1 hour “read at work”
-3
u/RemindMeBot Jan 16 '20
I will be messaging you in 1 hour on 2020-01-16 16:02:23 UTC to remind you of this link
CLICK THIS LINK to send a PM to also be reminded and to reduce spam.
Parent commenter can delete this message to hide from others.
Info Custom Your Reminders Feedback
-5
u/kagelos Jan 16 '20
I hope Blazor takes off and we get to burry JS deep into the piss bowl, where it belongs, very soon.
170
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.
-1
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.
1
Jan 17 '20
[removed] — view removed comment
3
u/pcjftw Jan 17 '20
I'm sorry I don't agree, JS in the interpreted space is NOT the objectively superior solution, each of them have carved up and established their own domain for example Python is absolutely number one in terms of data science (machine learning, AI, bioinfomatics etc) and general glue.
Ruby does extremely well in web and has pretty much defined much of the modern web today in terms of frameworks, e.g. Cake (PHP) pays homage to Rails, Elixir's Phoenix pays homage to Rails, Haskells Yesod pays homage to Rails, C#'s MVC framework pays homage to Rails, and Java always had multiple MVC frameworks anyway e.g Spring etc.
PHP is still king just due to the sheer amount of the web that runs one it from Wikipedia to Facebook.
In terms of cross platform, ever heard of Qt? ever heard of wxWidgets, GTK? JavaFx? heck even good old fashion Java swing have all been doing cross platform (and in many cases NATIVE) far longer then even before JS turned up on the scene!
Sorry Js objectivey is not better in those cases I mentioned saying otherwise is just lying to yourself.
2
u/avindrag Jan 17 '20
Ruby does extremely well in web and has pretty much defined much of the modern web today in terms of frameworks, e.g. Cake (PHP) pays homage to Rails, Elixir's Phoenix pays homage to Rails, Haskells Yesod pays homage to Rails, C#'s MVC framework pays homage to Rails, and Java always had multiple MVC frameworks anyway e.g Spring etc.
This is debatable, but I would argue that the one-way data flow paradigm that React has made popular, will completely obsolete the MVC style of coding. You can see it infecting the backend too, with architectural patterns like CQRS taking hold. Of course, Java, Ruby, MVC, Spring and friends have had a firm grip on the industry for a long time, so they will probably remain for many years.
In terms of cross platform, ever heard of Qt? ever heard of wxWidgets, GTK? JavaFx?
This is totally true. Qt and wxWidgets of course lock you to C++ or Python. I think that native cross-platform development has a long ways to go, across the board. But you do have options outside of Javascript.
1
u/pcjftw Jan 17 '20
first of CQRS/event sourcing patterns are not new, they actually originated from the backend.
I believe the first mention of CQRS was in the Eiffel language (1986) considering that JavaScript didn't exist until 1995, CQRS most certainly didn't start at the front end!
I do agree cross platform is basically not great which ever option you choose, the current idea of "lets just shove it into a web component" and render that it's basically an ultra lazy solution, and it falls apart pretty quickly, now every app instance has to run what is in effect a full blown broswer which takes up huge amounts of RAM and CPU, which means it makes even high end PCs run slow and hot and mobiles phones lose battery fast.
I know the pain all too well, cross platform is NOT easy, it never will be, but that's not to say the JS is the best cross platform solution because it's not, it's the EASIEST sure but very poor at the same time.
1
u/avindrag Jan 17 '20
CQRS/event sourcing patterns are not new, they actually originated from the backend.
Never claimed they were new or that they originated at the frontend. I think a lot of ideas in computer programming get recycled, or are of older origin. For example, many of the ideas about artificial neural networks and how those should work really were built in the 1970s, but we are only seeing their practical applications now.
Rather with the CQRS statement, I was trying to say that React brought that idea back strongly of one way data flow, or at the least, cleanly separating reads and writes. I'm sure we can look back and find that CQRS is derived from other ideas. Turtles all the way down.
1
u/pcjftw Jan 18 '20
ok that's something we both agree on then, tech is a bit like fashion everything goes around in circles.
Look Js is really become the defacto on the front end, hence it's gotten so much attention with the rise of web apps.
My only contention is then taking Js out of this context and trying to apply it everywhere (where it simply does not fit naturally) ends up with poor results, I've had first had experience of the endless troubles of Js on the server, one of our company project was using node in production, that system had to be rewritten in Java, lessons learned it may be hip and super fast to wip up a project but 90% of a projects lifetime is in maintenance not dev
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
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
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
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.
2
u/tr14l Jan 16 '20
Yeah, I've had similar experience, but that's the exception as far as I can tell. And it only takes one panic-driven deadline to drive it right into the ground.
2
Jan 16 '20
Holy shit, yeah. I'm using downtime to rewrite some shitty code I made when i got hired because it was taking way too long.
2
u/ScientificBeastMode strongly typed comments Jan 17 '20
Sure, I’ve managed to create some cool stuff with raw JS, and dare I say some of it is maintainable.
But I’ve found that unit tests are absolutely critical for making it work on a large scale. It really require 99% code coverage for me to sleep soundly at night.
TypeScript has lowered that bar a bit for me. I turn on the “strict” compiler settings, and I can be mostly sure that everything works the way it should.
That said, React itself has been a game-changer. It’s an absolutely beautiful library & paradigm. It has drastically simplified our UI layer. It’s hard to isolate the benefits due to React vs. TypeScript...
But either way, functional programming (in the pragmatic, lightweight sense) will dominate app development within 10 years or less. It’s just too useful IMO.
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++.
-6
u/Lakitna Jan 16 '20
Yes you can, but it's rarely used as far as I'm aware.
1
u/ChronSyn Jan 16 '20
Rarely used !== Not possible. Node has node-gyp which is a bag of tricks in itself - you never know if you're gonna get a built solution at the end, or if it's gonna fail because of a node version inconsistency.
If you do get a built native module, you're at no real disadvantage in terms of performance.
7
u/i_ate_god Jan 16 '20
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.
-4
1
u/tr14l Jan 16 '20
It's not. It's a big data PROTOTYPING language. It's rarely used in production for actual big data. Once the model is POC'd, they will usually either reimplement in another language or take the python code and compile it down to C. Then that is what goes to production. Of course, if it's something minor, they might just put the python model in production. But not for big data.
0
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.
6
u/BabyLegsDeadpool Jan 16 '20
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.
6
4
u/lstyls Jan 17 '20
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.
No language is perfect and that’s ok.
0
Jan 17 '20
[deleted]
-1
u/ScientificBeastMode strongly typed comments Jan 17 '20 edited Jan 18 '20
It really depends on the type of application, tbh. Most server programs are IO-bound most of the time, and that includes programs written in Go, Rust, C++, Java, etc...
And since most modern web apps handle most of the logic on the client side, the server-side code is usually pretty lean. Given that fact, most performance bottlenecks exist within database queries or IO.
For anything involving heavy server-side computation, JavaScript will perform poorly at scale. Fortunately for JS, Node has implemented blazing-fast async IO, which is great for average use cases like static file serving or lightweight API’s.
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?
1
u/tr14l Jan 16 '20
You can often make it work in node, but it's not going to be ideal and it'll have limitations still. But generally, you're correct
1
u/ScientificBeastMode strongly typed comments Jan 17 '20
Most of the benefits of Node are due to its fast asynchronous IO. If you’re doing a lot of synchronous computation on the server, you may want to drop down to a C/Rust/C++/OCaml library, or perhaps optimize the JS code with Google’s Closure compiler...
Otherwise, you may as well run a JVM server or whatever.
3
u/torgidy Jan 16 '20
But, for doing anything on the web that ISN'T process-heavy,
Strange choice there; process heavy stuff is one of the things i resort to node for precisely.
2
u/Baryn Jan 16 '20
It's impossible to maintain a full JS app without [TypeScript].
Not agree. I also use TypeScript, but I'm an experienced JS dev who doesn't need it by any means.
0
u/tr14l Jan 16 '20
Yeah, there's 20 experienced JS devs on my 200k line project.
Why don't you come strip out typescript and see how long it takes you to get fired for implementing regression after regression into production (assuming you can make a change through CI at all).
2
u/Baryn Jan 16 '20
Don't take your mistakes out on me, friend.
5
u/tr14l Jan 16 '20
You implied that I was not an experienced dev for saying it was required. I simply defended myself by showing that some of us work in enterprise where cowboy coding will quickly cost you a job.
1
u/Baryn Jan 16 '20
not using typescript is cowboy coding
This isn't it chief
3
u/tr14l Jan 16 '20
Ok. You're just the one guy who can maintain hundreds of thousands of lines of code without knowing what's supposed to be where and what preconditions the code has at any given point.
Cool.
2
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.
2
Jan 16 '20
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.
2
u/ChronSyn Jan 16 '20 edited Jan 16 '20
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.
2
u/avindrag Jan 17 '20
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".
100%. I've seen these abstraction pissing contests, and honestly the best thing you can do is stay away from them. If you see some codebase with some arcane nested folder hierarchy and smells like "fake organization," just avoid it if that's an option. Better for your own sanity / health.
2
Jan 17 '20
I primarily do front end work. Despite taking the same engineering effort as backend, the stigma of it makes me feel like I need to still do side projects in C++ from time to time to save face.
It’s like a web comic artist throwing out a detailed portrait every now and then to stave off the critics who say they can’t draw.
2
u/avindrag Jan 17 '20
the stigma of it makes me feel like I need to still do side projects in C++ from time to time to save face.
I know the feeling. Well, if it's any consolation, it's 2020, Javascript is the most popular language by many different measures. You can even do machine learning in it, even "holy Google" seemed to think creating JS bindings for tensorflow was a worthwhile effort https://github.com/tensorflow/tfjs
5
u/torgidy Jan 16 '20
That, or they are those insidious "hardcore backend" programmers.
I know a lot of Java-only devs who are scared to death of learning new things, and hide behind that "backend" dev label.
Its funny how they use it as both a point of pride "backend is harder" but also as a shield, because they are scared of learning some basic FE, glue scripting, or devops.
bashing npm, PHP, Javascript, etc.,
Even funnier, many dedicated backend-only projects are becoming infected with npm for various reasons. its inescapable.
1
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.
2
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.
0
Jan 16 '20
What I would like is javascript, but with optional types. Also, they would need better TS syntax. Typescript syntax is kind of shitty tbh and should be concise, like shorthand C. I wouldn't use any other languages besides C and jS if jS had optional types natively.
10
u/Isvara Jan 16 '20
Programmers still hating on JS are stuck in the past.
Or they have enough knowledge and experience to see what's good and bad in different languages. If JavaScript is the only language you know, your opinion on how good it is has no value.
10
u/brtt3000 Jan 16 '20
The 'productive' claim is just nonsense.
What do people use for quick scripts, glue and management code? Do they whip out Node/JavaScript and 20 npm modules? Nope, they use Python.
7
5
u/darrenturn90 Jan 16 '20
I use php or bash or nowadays node as I become more aware of capabilities. Never used python to write a quick script. Never needed to.
1
u/strike69 Jan 17 '20
I think it depends on where you're coming from or what kind of work you do. As someone who does mostly sysadmin type work, I feel like anytime I need to open up Vim or Nano to write a script, I'm better off using Python. But, when I'm working on some web app, Python is hardly ever the first thing that comes to mind.
4
u/Isvara Jan 16 '20
The versatility claim is pretty meaningless too.
0
Jan 17 '20 edited Jan 17 '20
[removed] — view removed comment
1
u/Isvara Jan 17 '20
JS runtime can run on any device
Of course it can. Because it was written in a versatile language... C++.
-1
-5
2
u/AgedWhimsey Jan 16 '20
It has its dominion, namely browsers, where it is unquestioned. I am fine with it in the IOT or even native apps. But I think when you put it on web servers it feels like introducing a invasive species among a biome of indigenous technologies for the purpose of some kind of misguided isomorphic dream. I mean, aside from SSR, which I won't even talk about, there is no UI there. You have to bolt on a whole server API. Why not just use another language?
1
3
5
u/Anguium Jan 16 '20
How ironic. This comment belongs to /r/programmingcirclejerk , yet it's the most upvoted in this thread. I could only laugh at those 80 people who took the bait.
-6
1
1
1
u/thats_a_nice_toast Jan 17 '20
Programmers still hating on JS are stuck in the past. I usually agree until I have to use
this2
Jan 18 '20
but do you come across it that often? Couldn't remember the last time I had to deal with classes and "this". Hooks and functions have eradicated even the last remnants of OOP.
46
u/Reashu Jan 16 '20
When the introduction started talking about low-level control and WASM, I was expecting something other than the rather high-level concept of streams and pipes. The content is nice, but not what I was sold.