Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JavaScript is Eating the World

dev.to

Post reply on HN
Print view View original

171–180 of 323 posts

Re: JavaScript is Eating the World

#171

Post by DonbunEf7 »

woah wrote: post #124
fundabulousrIII wrote: post #71

What they don't say in this panegyric to node is that.. 1. The language (js) is absolutely horrific. 2. node is single threaded and non-blocking/async in I/O for some operations but when blocking requires libuv and gymnastics. 3. It moves too fast for stability. I've encountered huge memory leaks with node at various versions that are terrible to debug. 4. It is designed to the lowest possible specification for devel…

There are languages that I like better than JS. However, JS servers power trillions of dollars of business. People who grasp for reasons to hate on JS are a little like people who get into flame wars about video game franchise rivalries. It's symptomatic of deep unmet emotional needs in that person's life.

Oh, of course, people dislike JS because they're unhappy inside. It can't be that JS is a lame language.

Re: JavaScript is Eating the World

#172

Post by dirkc »

krapp wrote: post #96

I feel like it's less Javascript that's eating the world and more Node and NPM. It seems as if it's impossible to publish a Javascript project without taking for granted that the developer has, or even wants , a package manager with dependencies, arbitrary toolchain and transpiler along with it. Maybe I'm just a dinosaur for not wanting my "build process" for javascript to be more complicated than including a script…

I felt frustrated by the typical Node toolchain until I remembered the typical Qt toolchain for developing cross-platform desktop apps. I can't remember everything, but here goes.

To compile a Qt app you need: - the meta object compiler (moc) to add dynamic features to C++ for Qt use - the Resource Compiler (rcc) to embed icons or sounds as arrays in header files - the Qt Quick Compiler if you are using QML files for your interface - the C++ compiler, linker, etc.

This is either driven by CMake, qmake or your IDE!! I see you can use Qbs to generate the CMake or qmake files! I remember learning CMake, make, ant, etc being non-trivial!

Oh, and you were on your own when it comes to dependencies!

Re: JavaScript is Eating the World

#173

Post by YSFEJ4SWJUVU6 »

I think it's interesting in its own right to point out that the trendy editors of today implemented in JavaScript are able to edit (and even view) files larger than about a megabyte because they are not any more fully implemented in JavaScript says something – and I'm of course not talking about the framework.

Re: JavaScript is Eating the World

#174

Post by fundabulousrIII »

ovao wrote: post #133
falcolas wrote: post #95

Earlier quoted context omitted.

That JavaScript was not designed to work as a *nix (or Windows for that matter) server language. And that any attempts to make it work as a server language are going to include some major workarounds to fit that round peg into a square hole. You can still make it work; but you can script a web page's interactions in C as well. That doesn't make it the right thing to do.

I'm not a particular fan of JavaScript on the server these days, but when you have a large number of developers who know JavaScript from the front-end world and a language ecosystem that's quite large and relatively robust, I would argue that doing those "major workarounds" (which aren't so major, really) to make server-side JavaScript an accessible option at least very closely resembles the "right thing to do". Shou…

No. We should collectively evaluate competency and correctness of a developer and language for it's best purpose as in any adequately run job interview.

Re: JavaScript is Eating the World

#175

Post by ericmcer »

fundabulousrIII wrote: post #71

What they don't say in this panegyric to node is that.. 1. The language (js) is absolutely horrific. 2. node is single threaded and non-blocking/async in I/O for some operations but when blocking requires libuv and gymnastics. 3. It moves too fast for stability. I've encountered huge memory leaks with node at various versions that are terrible to debug. 4. It is designed to the lowest possible specification for devel…

Why would you ever use the word 'panegyric' instead of article? Maybe you like to purposefully complicate things so that you can maintain your elitism? This might be related to your dislike of JS.

Re: JavaScript is Eating the World

#178

Post by seanwilson »

mschuetz wrote: post #155
flavio81 wrote: post #82

Earlier quoted context omitted.

The deeper problem is that JS is not strongly typed. Typescript gives you static type checks but the runtime is still weakly typed and will still do all sorts of weird type conversions.

Strong typing is a start but not enough for my taste. Static typing serves as documentation and compile time bug check, which is awesome to have. I'd like to have both, without the detour over typescript.

I don't think you're going to get strong types in standard JavaScript any time soon. Isn't TypeScript a very good compromise right now?

Re: JavaScript is Eating the World

#179

Post by pyrophane »

I think this is more reflective of the shift in how code and development teams are being organized rather than JavaScript "eating the world."

Now that many shops have separate back-end and front-end focused teams, a lot of API development is moving to node so that the front-end focused JS developers can maintain the APIs they consume themselves.

Also, while languages like Java are very good at helping large teams manage equally large codebases, deploying microserves and organizing code into smaller-more self-contained pieces make it easier to use things like javascript for individual services.

Re: JavaScript is Eating the World

#180

Post by kolanos »

vim_user wrote: post #145
gaius wrote: post #86

Earlier quoted context omitted.

Node's success has everything to do with the environment itself in combination with the language. Let's be honest: it is nothing to do with either of those and purely a matter of fashion. In a couple of years at most there will be a new new thing and everything will revert to version 0.1, keeping everyone busy but making no actual progress. Gotta soak up those CPU cycles the hardware people are giving us somehow righ…

After two decades in this industry, I've come to the same conclusion. Developers may use logic in coding, but trend-wise, we're bunch of herds following whatever others are doing. We forget whatever lessons we learned previously whenever something new comes out. It's good to see there are others who see insanity in it as well.

There is a logic to following trends, but it has nothing to do with the problems being solved and everything to do with remaining relevant in the workforce.
Post reply on HN