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

91–100 of 323 posts

Re: JavaScript is Eating the World

#91

Post by crimsonalucard »

Brockenstein wrote: post #56
nilved wrote: post #6

What a depressing idea. I don't take JavaScript seriously at all.

It is an interesting example of how a camel is a horse designed by committee. And basically the reason we have JS is because we can't agree on anything else. So JS is what we've got. But you should take JS seriously, because it's what we've got. It's not going anywhere. And it powers the Internet. And for right now the Internet is the end all, be all, technology.

An alternative has already been agreed upon and may be the future of front end web development. It's called WebAssembly.

Re: JavaScript is Eating the World

#92

Post by crimsonalucard »

alayek wrote: post #52
nilved wrote: post #6

What a depressing idea. I don't take JavaScript seriously at all.

Sorry to say this, but this kind of statements don't really add anything to the discussion. _Only a sith deals in absolutes_. Recently, JavaScript has adopted lot of language feature from C#, Ruby etc., that make it really useful for most common tasks. And the community moves really really fast, hence adoption of new language syntax is quite fast. JavaScript has some killer platforms / apps, that are being used in pr…

It's not the technology surrounding the language, it's more of how the core language itself is flawed.

Re: JavaScript is Eating the World

#93

Post by flavio81 »

talmand wrote: post #37
jchw wrote: post #20

JS has the appeal that it's something a lot of people already have good amounts of experience with. And ES2015+ features add to the learning curve, but also give some much needed aid to existing problems; it's easy to pick up on async/await when you already know how promises work. Meanwhile, trying to find Go developers can be a challenge. And the learning curve is low, but there's plenty of low-level gotchas like de…

I'm beginning to think npm has joke potential like regex. "I had a problem. I started using regex and now I have two problems." Becomes... "I had a problem. I ran npm install and now I have 21,735 problems."

For me, going from Lisp package installs to Node package installs was like traveling from a Bahamas beach to Siberia, with the same clothes.

ES7 is okay, Node.js is good, V8 is GREAT, but NPM is an atrocity.

Re: JavaScript is Eating the World

#94

Post by fundabulousrIII »

jononor wrote: post #58
jcelerier wrote: post #27

Earlier quoted context omitted.

> In Node, you are not supposed to block the event-loop that runs in that single thread and queues the tasks. well, sure, but ten years ago it was already a given that one would just spawn one event loop per thread and have them communicate with messages, so why is it so hard for node ?

I/O is not going to be any faster by having more threads. More threads are not gonna give you more RAM either. And CPU-bound tasks are only faster if the OS you are running in exposes multiple CPUs. With VMs and containers with focus on horizontal scaling (many relatively small machines) that is not the case either. Effectively the message-passing communication between threads still exists, but has moved outside the…

Your paradigm is showing.

Re: JavaScript is Eating the World

#95

Post by falcolas »

todd3834 wrote: post #74
falcolas wrote: post #43

Earlier quoted context omitted.

It honestly doesn't give me pause, since the impedance mismatch between JavaScript and backend programming is so great. To me, the fact that Node has to add a library with custom semantics just to allow a basic 'open' on a file handle is a huge warning flag to me.

What does it warn you about? Not trolling, honest question.

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.

Re: JavaScript is Eating the World

#96

Post by krapp »

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 tag. That's probably what it is.

Re: JavaScript is Eating the World

#97

Post by [deleted] »

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…

[deleted]

Re: JavaScript is Eating the World

#99

Post by onion2k »

tomascot wrote: post #68
onion2k wrote: post #60

What you build is infinitely more important than what you built it with. If someone writes a better Google the users won't care if it's using Javascript, Rust, or QBasic. They'd still be all over it.

I had a client that asked me to rewrite our software in JS. He didnt know anything about programming but said he preferred JS.

That problem has nothing to do with programming languages.

Re: JavaScript is Eating the World

#100

Post by andrewstuart2 »

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…

> It is designed to the lowest possible specification for development: web developers.

This is not a productive comment.

Post reply on HN