JavaScript is Eating the World • Hacker News Board

Re: JavaScript is Eating the World

#281

Post by sk5t » Thu, Aug 24, 2017, 10:43 PM UTC

fao_ wrote: post #197

sk5t wrote: post #36

Earlier quoted context omitted.

Few but you likely consider the implementation part of the language.

C explicitly states what an implementation should and should not do. The same with C++, FORTRAN, and other standards. Javascript is a standard written by committee. So why can't it tell implementations what is good behavior and what isn't? Other languages do.

I think there's a distinction to be made between the language spec (e.g., interesting Javascripty details like what is the result of `"" + 1`) and integration issues like what to do when the browser window detaches, how many threads the browser will devote to running Javascript, what to do when some of those threads appear to be blocked, or how should the runtime/VM attempt to recover from deadlock or OOM.

Re: JavaScript is Eating the World

#282

Post by peterashford » Thu, Aug 24, 2017, 10:48 PM UTC

specialist wrote: post #134

hood_syntax wrote: post #4

The more time goes by the more I feel crazy for missing whatever would motivate people to use js for anything more than is strictly necessary. Single threaded server??? I mean come on man, I understand you don't need parallelism for a lot of use cases but even if that fits your situation why javascript? It can't be that hard using a different language. I refuse to believe that.

My day gig is nodejs. I was interested in the problem space, didn't think too much about the stack. How bad could it be, right? Oops. The worst aspect of nodejs is code construction (craftsmanship). Whereas Bill Joy said of Java "Allows you to think both In The Big and In the Small, at the same time." With nodejs, not only is there no Right Way, there's not even a Good Way. You have to mind all the details, plus quit…

"I find the current state of affairs (emperor has no clothes) appalling and baffling."

JS is the only language on the browser after Java and Flash were killed off.

Brendan Eich created JS.

Brendan Eich runs Mozilla.

No new browser language occurs unless the big players (including Mozilla support it)

Mozilla have killed all attempts to add new languages to the browser.

Q.E.D. - language monoculture due to one creator forcing his creation on everyone and denying anyone the chance of doing things differently.

At least Web Assembly offers some hope for a sane future where we can actually choose the right tool for the job rather than the only tool for the job.

Re: JavaScript is Eating the World

#283

Post by jcelerier » Thu, Aug 24, 2017, 10:48 PM UTC

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…

> I/O is not going to be any faster by having more threads.

the world doesn't revolve around making HTTP servers. Maybe you aren't writing apps that do parallelizable serial computations but please don't generalize.

Re: JavaScript is Eating the World

#284

Post by dragonwriter » Thu, Aug 24, 2017, 10:50 PM UTC

peterashford wrote: post #282

specialist wrote: post #134

Earlier quoted context omitted.

My day gig is nodejs. I was interested in the problem space, didn't think too much about the stack. How bad could it be, right? Oops. The worst aspect of nodejs is code construction (craftsmanship). Whereas Bill Joy said of Java "Allows you to think both In The Big and In the Small, at the same time." With nodejs, not only is there no Right Way, there's not even a Good Way. You have to mind all the details, plus quit…

"I find the current state of affairs (emperor has no clothes) appalling and baffling." JS is the only language on the browser after Java and Flash were killed off. Brendan Eich created JS. Brendan Eich runs Mozilla. No new browser language occurs unless the big players (including Mozilla support it) Mozilla have killed all attempts to add new languages to the browser. Q.E.D. - language monoculture due to one creator…

> Brendan Eich runs Mozilla.

Ran. Very briefly.

Re: JavaScript is Eating the World

#285

Post by ovao » Thu, Aug 24, 2017, 10:57 PM UTC

defined wrote: post #264

ovao wrote: post #229

Earlier quoted context omitted.

> what don't you understand Exactly what I asked. > Any educated comment on these sentiments? Without clarity on the sentiments themselves there's not a lot to elaborate on without simply fumbling in the dark. If the concern, though, is that, in Node, you live and die by an asynchronous event loop, I'd say that's not a small footgun. I don't think that's in dispute. I'd also say that the presence of footguns doesn't,…

JavaScript is objectively, demonstrably a badly-designed, error-generating language for which countless libraries, generators, and higher-level languages and frameworks such as Elm and TypeScript have been created to compensate for its shortcomings - and it most especially does not belong on the server side. It is the poster child for the "If the only tool you have is a hammer..." maxim. Its appeal derives almost com…

I really don't disagree on any particular point. I only take issue with the suggestion that it simply shouldn't be an option. In the past I probably would've said the same about PHP, which sits pretty squarely in the same camp as JavaScript for its "victory despite design".

All things considered, a craftsman simply uses a tool to do a job. Often it doesn't involve much fanfare. I wouldn't say that modern JavaScript is quite as blunt an instrument as a hammer, but hey, if you're good with a hammer...

Re: JavaScript is Eating the World

#286

Post by Spivak » Thu, Aug 24, 2017, 11:01 PM UTC

shados wrote: post #255

nightski wrote: post #251

Earlier quoted context omitted.

There are three players in the game right now all of whom can push updates to the vast majority of their user base very quickly. This isn't a problem like it was back in the day. Now it's pure stubbornness.

4 players (edge, firefox, safari and chrome, and no the last 2 are no longer close). One of them, the usual suspect, is still dog slow to update. But even with that, wasm, service workers and other major changes don't come overnight. The rest of us still have a job to do.

I mean you're not wrong. If any major player added an existing mature language to the browser with 1st class support you would see the end of new JS.

Bonus points if it was a lisp or a 'hard' language because machismo alone would drive adoption overnight.

Re: JavaScript is Eating the World

#287

Post by peterashford » Thu, Aug 24, 2017, 11:05 PM UTC

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.

That's really very arogant. If people don't like JS, there's something wrong with them emotionally? Jesus wept! I happen to think there's nothing wrong with being annoyed that in the biggest marketplace in modern IT - the Web - we have ONE option for programming solutions. One! As engineers, I don't think it's unreasonable that we should be able to choose the best tool for the job, not the only tool for the job. That doesn't mean that JS is useless (or that I have emotional problems) but that other languages might be better suited to various tasks. That seems to a me a plain and uncontroversial statement that doesn't require positing mental defects to explain people who disagree with you.

Re: JavaScript is Eating the World

#288

Post by quacker » Thu, Aug 24, 2017, 11:10 PM UTC

always_good wrote: post #236

quacker wrote: post #211

Earlier quoted context omitted.

They didn't mention anything about typing as reason for switching. They said "It's a really frustrating ecosystem to work in, all the deps, toolchains, build process is extremely fragile." They switched to python for the ecosystem and tooling.

I don't understand the distinction. JavaScript tooling is notoriously complicated on the front-end, not the back-end. And I doubt they're saying that they switched to Python on the front-end.

> I don't understand the distinction.

The distinction was that cdnsteve was motivated to switch to Python due to issues with the toolchain and build system, not that JavaScript was weakly-typed.

> JavaScript tooling is notoriously complicated on the front-end, not the back-end. And I doubt they're saying that they switched to Python on the front-end.

You have a good point, though you still have to pull in dependencies and deal with NPM when running JS on the server-side (especially if the server is doing non-trivial stuff). Idk, maybe an approach with server-side rendering using Python did away with much of the JS usage which made things nicer.

Re: JavaScript is Eating the World

#289

Post by crimsonalucard » Thu, Aug 24, 2017, 11:15 PM UTC

kin wrote: post #160

crimsonalucard wrote: post #88

Node scales well in terms of performance. However does it scale well in terms of code complexity and readability?

Because it's not opinionated, it all depends. IMO the code base where I work is very complex but it's very easy to onboard new engineers with it. This is due in part to enforcing documentation and code style guidelines.

Is that a good thing? I would argue that enforcing guidelines can make any type of code base workable.

The holy grail is a language that enforces guidelines itself, for example: a type system.

Re: JavaScript is Eating the World

#290

Post by kin » Thu, Aug 24, 2017, 11:36 PM UTC

crimsonalucard wrote: post #289

kin wrote: post #160

Earlier quoted context omitted.

Because it's not opinionated, it all depends. IMO the code base where I work is very complex but it's very easy to onboard new engineers with it. This is due in part to enforcing documentation and code style guidelines.

Is that a good thing? I would argue that enforcing guidelines can make any type of code base workable. The holy grail is a language that enforces guidelines itself, for example: a type system.

I think static vs. loosely typed both have their pros and cons but that's the thing that's great about the Javascript community. It's not opinionated on things like this. So if you want statically typed, then you can code in Typescript.

This is in contrast to something like Rails which is super opinionated and doesn't give you much of a choice if you as a developer or even as a company as a whole were to disagree with these opinions.