A reply to today's The JavaScript phenomenon is a mass psychosis...
Let's start from the top.
An address from Mr.President of some company:
I recently received this kind message on LinkedIn from the president of a Canadian cybercrime technology companyThis should have nothing to do with anything. Anyone can be a president of anything. It's a fallacy to think because some president has sent you a message about JavaScript that what you say is suddenly validated. Especially when said president didn't use JavaScript at all, but merely sold product:
I ran a software business for a couple of years. It got bought and right now Im developing the very product I used to sell.And then goes on to say:
My former employees put AngularJs and Node.js in there. I remember my conversation 3 years ago with my best engineer : he said that javascript was taking over everything. I thought “Wow. They managed to fix that horrible language”Hm, JavaScript was horrible for you, yet you decided to develop your new product with it? Sounds backwards to me. What makes JavaScript (today, or even the past...4-5 years) horrible anyway? There is horrible JavaScript code but that isn't the language's fault. And they said 3 years ago. Today JavaScript is essentially on-par with Python, Ruby, or any interpreted language, even better with types when using TypeScript.
The thing is, there is a mass psychosis about JS and it’s like everybody is pretending that it isn’t awful.Well it isn't awful. Mr.President is just out of the loop.
And then, as if this wasn’t bad enough, someone had the brilliant idea of putting this thing in the backend....Yes, putting the most advanced interpreted language in the world in the backend is a brilliant idea. What is bad about this?? Speed? NodeJS supports FFI - no more speed issues if you can link in assembly modules.
Nodejs is costing millions per year to naive companies who are adopting it. You were wondering who they are: they are startups and small companies.<language> is costing millions per year to <adjective> companies.
Mind you, these engineers are smart, but they’re weak against crowd thinking.So general consensus is a bad idea now?! These engineers choose JavaScript because it offers benefits other languages didn't. Not all engineers are "smart" either.
So it got me thinking a lot about this JS situation, and the only plausible explanation is this :
Frontend has been despised by engineers because it is less scientific and more intuitiveThis is embarrassing. Engineers are just people. I have never once seen frontend being despised by engineers. Ever. Physicists despise musicians because they're less scientific?? No, this is a ridiculous "plausible explanation".
also because tooling has failed us over the yearsI guess all those frameworks over the years failed us then. I guess multi-billion dollar companies that created JS tools should just stop, eh? Because they aren't successful and wasting millions per year...
So designers have picked up the ball and now they want to program, the result being NodeJSNo. Server-side JavaScript predates NodeJS. Netscape's LiveWire Pro Web was created by the people who brought you Firefox, among other things. NodeJS was developed by a programmer, not a designer (I'm unaware of his interests, but he may be interested in designing too - who cares!). NodeJS is only 8 years old, and has come a long way. Apache is 22 years old and has its issues too - where's the criticism?
Designers are no engineers and vice versa, we should stick to our respective strengths.Uhh, polymath? No way am I sticking to one strength in my life. There is so much to learn.
At my new company, everyone was pretending that JS was alright. I got tired and spoke up. Turns out, deep down they all hated JS, it was just crowd thinking. Now they all hate JS. And we’re waiting impatiently for Web Assembly.There is always love/hate for anything. Nothing is perfect. It all depends who you ask.
Now a message from some guy on the Internet
It confirms what I knew all along: that JavaScript programmers have been mind-fucked into thinking that JavaScript is a good programming language.No a president giving his 2 cents does not confirm anything.
As most people well know, all programming languages have their faults. Some have more than others. However, JavaScript is especially bad. That’s why you can find so many complaints about JavaScript on the web.Or maybe it's because there are so many people using it? Because universities, colleges, high schools, afterschool programs, and a plethora of other organizations are teaching it?
One of the most amazing and distressing things about JavaScript is that it can actually fail silently at runtime due to syntactical errors!I actually haven't had this happen to me once, in the 5+ years I've been using JavaScript.
Another thing is “callback hell” which promises can mitigate but are otherwise not a perfect solution.So what is, the perfect solution? Surely another, better language has implemented it, and JavaScript can steal the idea?
The most notorious of JavaScript’s faults is probably in its weak typingTo some people this is a strength - again depends who you ask. I don't think it's a strength.
ask yourself this question: What other modern programming language is so bad that a linter is most recommended for safety sake?A compiler is a sort of linter. One of its tasks is to check all syntax is correct. So basically any modern compiled language answers this question.
But you do have options! You can use languages that transpile to JavaScript.Yes! Yes, if you do not like JavaScript, there are a bunch of options, and even more once WebAssembly is ready. I will continue to use JavaScript/TypeScript even after its arrival.
I’ve been writing web applications for over a decade and it’s utterly shocking how little JavaScript I know!...Doesn't this put you in a bad place then, if you are writing a big rant about it?
So it’s really your choice. It’s up to you whether you want to dive into the chaotic world of JavaScript. That’s where the money is in terms of front-end jobs. But that’s also where the unholy mess of JS web frameworks is, which leads to “framework fatigue.”Yes. Yes. Yes. Yes. My solution to framework fatigue: learn what's the most popular at the moment and don't jump ship as soon as you see something at the top of some news site. At the moment the contender for #1 is React. That is what I'd learn now. The way we develop front-end applications will stay the same mostly because we've now adopted component-based development practices. I can jump from Angular 1.5+, Angular2/4, React, Vue with little resistance. It is fantastic.
These frameworks have the lifespan of a fruit fly!> Angular 1 has been around for 7+ years. As long as NodeJS.
OTOH, any dynamic language runtime is just a lousy C program that takes toy input.
ReplyDeleteImagine a parallel universe or the future or whatever, sufficiently advanced in CS to have composable systems built from the HDL level, through some kind of macro-assembler process up to high level, like the promise of Cython or your vaunted JS FFI interface
ABI level interfacing between components glued together with high-level spec languages.
TS could be a reasonable high level specification language. Heck, YAML would work fine, and fields for types are basically just cookie-cutter memory stride sizes etc.... it ain't rocket science...
Now, I'm not saying you CAN'T do with with JS, but you can't do it without ambiguity and problems that are strictly created by JS!
JS was made in a few weeks as the internal scripting shell for a program, and while Brendan basically got something of a workable basis going for the purposes it was required for, this abomination of pretending that Classes exist are nonsensical!
Using fancy tools and TS to specify a LESS precisely typed language loses information!
This entire charade IS a cult, it IS a waste of both electricity and CPU/RAM, and we SHOULD strive for better.
Haskell, Ocaml, TS, ML stuff, etc and even just good old declarative markup languages, all seem to grok the idea of how high-level steerage of precisely cookie-cutter modules passing pointers to each other SHOULD work...
Let's aim higher.
JS is for web browsers, and ideally ES5 and including MAYBE something like Mithril at MAXIMUM is OK, but this is only for one reason:
The web was invented as an asynchronous remote folder and document browsing platform for people that trusted each other to some degree.
Trying to treat it as a 2-way-binding GUI or whatever, is a hack, an addon, and has caused a lot of pain. The desire to avoid page reloads opened Pandoras box, and I understand and accept what the issue is: people want a remote RPC gui, they want the world-wide X-windows, lol...
Ok, but node.js is an unnecessary wart, come ON>.. insisting upon having that in your server stack instead of using Java or Crystal or PHP is like saying "let me just add a *little* poop to the soup" ... no need to bring that flavor on board.
Sincerely, an ex-Node-Js user who accepts browser JS for what it is...
*stride sizes, lol, I meant offsets... a struct where the offset indicates which member you are accessing...
DeleteSorry, the point about avoiding JS on the server is that stuff like http request response and other data structures are well defined, etc, and that long running processing efficiently passing pointers and being aware of the shape of data is light years ahead of some GC heap driven chaos generator wildly doing it-knows-not-what but busy being drivable by something ripped away from it's Window while it was still nursing that also knows-not-what shape ANYTHING is and which is meant to run around in circles in single file fashion while still managing to not guarantee anything about execution order or timing or anything...
Delete