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

JavaScript is Good, Actually

ashfurrow.com

Post reply on HN
Print view View original

311–320 of 369 posts

Re: JavaScript is Good, Actually

#311

Post by _o_ »

pjmlp wrote: post #288
hajile wrote: post #237

Earlier quoted context omitted.

There's currently zero support for efficient garbage collectors and no Dom API access. Until a few more primitives are added, wasm is a pipe dream. Even once support exists, there's a payload issue. Nobody wants to spend loads of bandwidth downloading runtimes.

That is just FUD. It is certainly possible to package a runtime way smaller that the analytics crap most people have to endure. Unity WebAssembly games are just a few hundred KB. Who cares about DOM, WebGL takes care of the UI part.

I agree. DOM will come, thinking that GC can not be developed in language the browser (and javascript) is built in is a bit naive (not to mention GC is a complex solution for simple non-problem, I would rather use malloc/new and free/delete + destructors than relying on Terminator Skynet ripped AI doing this really simple task - tribute to java and inability to free memory when needed! Anyway with each tab running in separate process, system will take care about memory leaks ;) ) while the runtime - the last time I checked, the CDNs were serving javascript libraries over mb in size and I really see no problem for them serving python runtime, while for c++, the runtime can be the browser itself and even if you pull in libc or proxy to the existing browser functions, this can be really, really small. Believing that code, that was designed to be human readable (as js), can be shorter than the opcodes doesn't really fit here.

I have heard this runtime considerations before but they are taking into account that someone will run webassembly compiled JRE in browser (and I am sure that right now, there are some freaks trying to achieve that). But there is still good old C++ (or Rust) not as productive as scripting languages but this is just due to much less open source "technological stack" (or some might argue, tribute to low quality of software today, "technological garbage") rather of not beeing capable of beeing competitive.

I think that the coolest trick that web based technologies pulled out was to convince the world, that the whole GUI needs to be primitive, simplistic, as they were unable to create something that desktop applications were doing for decade (speed/size considerations) and it might just happen that we will return back to owner drawn controls, where you wont be able to make distinction if app is running locally or in browser (no, I don't mean Electron, pun intended). There js will be unable to compete.

Anyway, push for webassembly is not here as corporations want to do something good. They want to push all computer users into old mainframe scenario, where you would have to rent space and cpu in a cloud and have just dumb terminal and javascript has hit its limits to replace desktop environment as it is, even with Windows Metro look (another simplification of GUI, done for mainframe scenario, Windows 365 are not far away)

Javascript was usefull in era of simplistic web pages as a small hack into html, but for next step we need something more and here there are other languages that can offer much more but are now limited to running in backend as they don't have browser support. But this will change with webassembly.

Re: JavaScript is Good, Actually

#312

Post by hajile »

cm2187 wrote: post #279
hajile wrote: post #237

Earlier quoted context omitted.

There's currently zero support for efficient garbage collectors and no Dom API access. Until a few more primitives are added, wasm is a pipe dream. Even once support exists, there's a payload issue. Nobody wants to spend loads of bandwidth downloading runtimes.

The runtime is probably still be a fraction of the bandwidth consumed by all the photos and videos on modern websites. But the web is only one aspect. Web apps are likely going to take over a huge part of client development.

Runtime size depends on a few things. The biggest is JIT vs native. If you're willing to dedicate the time to making (or interfacing with) a completely native compiler, then the runtime penalty isn't that large. In contrast, any halfway decent JIT is going to be several MB of code (and unlike an image, has to be parsed and executed -- potentially on slow phones).

In both cases, the GC issue is non-trivial. LLVM has finally started to make performant GCs possible. Wasm (to my knowledge) doesn't have similar capabilities and guarantees (I suspect the are actually impossible with untrusted GC code). The only viable solution IMO is the addition of GC primitives and hope that your particular language maps well on that specific browser's GC.

https://medium.com/dartlang/dart-on-llvm-b82e83f99a70

Re: JavaScript is Good, Actually

#313

Post by Izkata »

slikts wrote: post #137
wruza wrote: post #39

Semantics and configurability is what what makes a language great. JS doesn’t have function environments, i.e. every unlexical lookup goes to global/window and that cannot be redirected. It doesn’t have green threads (at least). There are generators, but one cannot just yield without marking all the functions generators too (async/await in modern terms). Stack traces are lost when generators throw(). JS has no good i…

The generators or async/await in JS are 'shallow' coroutines because you can only `yield` or `await` in the direct scope of a generator or async function, but the benefit of shallowness is that the control flow is explicit; you don't have to consider whether a function call will suspend the calling context's execution or not. I find the explicit clarity to outweigh the reduced power of shallow coroutines. As an aside…

> As an aside, there exist green threads in JS, namely node-fibers, although it's only a Node.js extension.

Aren't Web Workers real threads, and supported natively in browsers? (Haven't used them myself, maybe there's some limitation that excludes them from the criteria above...)

https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers...

Re: JavaScript is Good, Actually

#314

Post by 2RTZZSro »

dx034 wrote: post #268
2RTZZSro wrote: post #257

Earlier quoted context omitted.

That python is slow is utterly irrelevant. You would never deploy an unoptimized Python codebase into production if you cared about performance. You would profile the code and optimize the hot paths with the appropriate technology, be it numba-jit, cython, numpy, cffi, or any of the other many ways you can easily optimize Python

I wouldn't but I've seen a lot of people who will. If you have code that runs, why spend extra money to optimise it? Hardware is cheap and the cloud allow to scale as much as you want (not my opinion obviously but I've heard that more than once and I'm not even directly involved in these kind of decisions).

Clearly if there is no incentive to spend money to optimize it then it is fast enough.

Re: JavaScript is Good, Actually

#315

Post by _o_ »

hajile wrote: post #301
pjmlp wrote: post #288

Earlier quoted context omitted.

That is just FUD. It is certainly possible to package a runtime way smaller that the analytics crap most people have to endure. Unity WebAssembly games are just a few hundred KB. Who cares about DOM, WebGL takes care of the UI part.

Consider python. With all the built-in libraries, it's many MB of code. If my app is 1-2mb, I'll be pushing the limits (I'll definitely be looking at multiple bundles to reduce and spread out the load parse time). If that goes up to 10-15mb (which can't be split), you're now going to have major usability issues. That's before all that analytic stuff that isn't going away. People do notice the difference and will just…

Sorry but I believe you are wrong in basic presumptions. If they will do it properly, in c++ compiled to webassembly scenario, there will be no need for parsing (except some headers). Browser code (V8 in chrome?) will just take the opcodes and execute them, similar as CPU execute machine code in native applications. But normally, if this is a scripting language like, lets say python, that webassembly compiled python "runtime" will need to parse python source code (or not, there are pycs if I remember correctly) and there will be parsing overhead. But for compiled languages there will be "no" overhead (browser on its own is overhead) and in any case far less than for javascript (that really needs to be parsed).

Anyway, if you remeber flash, there was one runtime for all flash apps and once you had it, this was it (until next security update :D), and with todays CDNs, it will be no different than, for example, angular. Downloaded once, cached forever.

Re: JavaScript is Good, Actually

#316

Post by pjmlp »

_o_ wrote: post #311
pjmlp wrote: post #288

Earlier quoted context omitted.

That is just FUD. It is certainly possible to package a runtime way smaller that the analytics crap most people have to endure. Unity WebAssembly games are just a few hundred KB. Who cares about DOM, WebGL takes care of the UI part.

I agree. DOM will come, thinking that GC can not be developed in language the browser (and javascript) is built in is a bit naive (not to mention GC is a complex solution for simple non-problem, I would rather use malloc/new and free/delete + destructors than relying on Terminator Skynet ripped AI doing this really simple task - tribute to java and inability to free memory when needed! Anyway with each tab running in…

One of those freaks is called Microsoft.

https://blogs.msdn.microsoft.com/webdev/2018/02/06/blazor-ex...

Re: JavaScript is Good, Actually

#317

Post by WorldMaker »

jchw wrote: post #256
yedava wrote: post #223

Code spends most of its time being in production and not in development. During that time in production, developers will leave the team, bugs will show up, major enhancements will be made. So it is important that the codebase is easy to reason about, easy to refactor and easy to debug. If you take a language like Java and an IDE like Eclipse or Intellij IDEA, it is trivial to find from where a particular piece of cod…

TypeScript offers a compelling case, however. It often can provide the refactoring superpowers of strong statically typed languages on top of JS, and its brand of structural typing allows for quite expressive, but type safe, programs. That being said, TypeScript is not sound and obviously in a real TypeScript program you'll eventually touch things that are untyped. But still, getting a different set of trade-offs tha…

It's useful having a spectrum types. I personally prefer noImplicitAny in Typescript as that lets me choose which battles to pick and while I often leave more `any` typed things than I would like, I have the `any` keyword as an explicit TODO marker of those places where I gave up, so I can go back and fix them as needed/time permits/tech debt requires.

Re: JavaScript is Good, Actually

#318

Post by handbanana »

ZvG_Bonjwa wrote: post #155
sloxy wrote: post #93

Earlier quoted context omitted.

That's interesting because I also picked up on that: "I am a world-class software developer living in New York’s East Village" and I just thought, hmm, here's this guy with ~5 years of ~professional dev(mainly with iOS) and he self qualifies himself as world class. Looking at his bio, I see he's worked for 3 companies doing quite ordinary things. I would love to know what gave him the confidence/ignorance to describe…

Oh, come on. So the guy uses some harmless exaggeration when selling himself on his own personal website & you're taking him to programmer jail over it? Do you frequently launch into personal attacks on authors whose articles you disagree with?

I think its valid to point out.

If the author is joking about being world class, that would be kind of odd. So is saying you're world class at something in general (unless you're the tiger woods of that something and can demonstrate/back it up).

I have found it is commonly a trend with frontend/javascript/rails devs to be senior/lead/etc after a few years of experience. I think there's a variety of reasons for this, but going back to the author he probably is very adept at his given field. But to brand yourself as world class seems a bit much.

Personal attack? Nope. But if I saw that line before interviewing a candidate - I'd definitely probe them about it

Re: JavaScript is Good, Actually

#319

Post by WorldMaker »

atomicnumber1 wrote: post #90
ajeet_dhaliwal wrote: post #45

My developer friends do have opinions on JavaScript that are in my view outdated, modern JavaScript is my favorite peogramming language due to the ease of expressivenesss and joy to write it. I started out with C, C++, Java, Objective-C and C# before ever seriously using JavaScript (other than tiny snippets of front end browser dom manipulation) and may be I’m just getting old but... I’d love to use JavaScript for ev…

I find swift and python to be more elegant in terms of expressiveness. Only issue with swift is that it's ABI isn't stable yet and still not official support for windows (I think, will need to check this).

At this point the only thing I feel like I'm left missing from Python in semicolon-free ES2015+/Typescript are list/generator-comprehension syntax [0] and slice notation [1].

[0] The Pipeline Operator Stage 1 proposal is currently the closest proposal to making something like that happen: https://github.com/tc39/proposal-pipeline-operator

[1] Stage 1 Proposal: https://github.com/gsathya/proposal-slice-notation/

Re: JavaScript is Good, Actually

#320

Post by wruza »

slikts wrote: post #258
wruza wrote: post #94

Earlier quoted context omitted.

If we’re talking about “dynamic CRUD over socket abstracted to death”-style tasks, and not considering minor preferences like syntax, then python, lua, most of lisp/schemes, perl. All of these allow enough meta-anything to do: ./file.src: func api_foo() for x in objs x.a = fetch(x.b) ui.btnok.enabled = yes commit() And have foo exported as api, and when called, all clients/servers, databases synced, validations passe…

The criteria for this list of languages seems to have been "isn't JS". The story for metaprogramming in JS certainly is limited in some aspects; for example, there's no operator overloading and JS isn't homoiconic like lisps, but between dynamic inheritance in older JS and the newer additions like proxies, symbols, accessors, reflection API, protocols and being able to extend the 'exotic' behavior of arrays, JS can p…

I tried to include all my rant points into this example. E.g. what if fetch() doesn't go async? Then we don't have to mark it like that and don't have to await. Where ui and commit lives? There should be a unique environment for this specific api call or a whole subsystem. objs is something both enumerable and proxied, etc. It can be done in JS, but IRL it will be:

  ./file.js:
  function foo(ctx) { // @export
    for (let x of ctx.objs.iterate()) {
      x.a = await fetch(ctx, x.b);
    }
    ctx.ui.btnok.enabled = true;
    ctx.commit();
  }
  autoexport(module, x => eval(x));
And more boilerplate, ceremony and fud down the way, if you go vanilla.

(Thank you and all commenters here for sharing your code and experience. In particular, symbol-land looks very interesting and haskell-y.)

Post reply on HN