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

The Birth and Death of JavaScript (2014)

destroyallsoftware.com

Post reply on HN
Print view View original

101–110 of 144 posts

Re: The Birth and Death of JavaScript (2014)

#101

Post by eikenberry »

_the_inflator wrote: post #18
jdw64 wrote: post #11

JS became a compilation target (and it really did), and back then in the video it was asm.js (that's been deprecated, hasn't it?), but then WebAssembly came along... Seeing it actually being implemented and running natively, it seems his prediction was accurate. I mainly use TypeScript myself, and now with Electron, web technologies are wrapped into desktop apps, so web syntax has even entered computer programs. Peop…

JavaScript is the new assembler layer so to say. Every compiler as per definition translates human readable code into machine language. The benefit of JavaScript is, that, after Google really pushed it to its limit with V8 and of course NodeJS made it a backend dream, that it is ubiquitous and once written usable everywhere, much kinda like PDF. Its versatility gave it the advantage over WebAssembly to this day, beca…

> course NodeJS made it a backend dream

More a nightmare than a dream. It lead to the terrible practice of tightly coupling frontend and backend code bases that led to inevitable pain. The language barrier between front/back-ends was a key aspect of web-dev that allowed it to a foothold vs. previous, unsuccessful attempts. Fortunately this practice hasn't taken over and sane architectures are still prevalent.

Re: The Birth and Death of JavaScript (2014)

#102

Post by naveen99 »

Dwedit wrote: post #39
naveen99 wrote: post #19

interpreted languages carry a lot more context than compiled ones. Sandboxed compiled languages don’t have the context baggage, but come with other parts of the brain dead.

I don't think Javascript is still interpreted though?

Sandboxed

Re: The Birth and Death of JavaScript (2014)

#105

Post by conartist6 »

sph wrote: post #95
eranation wrote: post #49

Surprised no one mentioned this is the guy who brought us this masterpiece. If you haven’t seen it, drop everything and watch it, best 5 minutes of your day guaranteed. https://www.destroyallsoftware.com/talks/wat

All his talks are very good. ‘Boundaries’ is probably the most illuminating video I have ever seen on software architecture, its lessons I still think about when I design any complex application. Incidentally it’s also a great introduction to thinking as a functional programmer if you are used to imperative logic with state spread all over the place. https://www.destroyallsoftware.com/talks/boundaries

is there nobody else who thinks "A Whole New World" was the best one?

Re: The Birth and Death of JavaScript (2014)

#106

Post by sheept »

moritzwarhier wrote: post #65
noman-land wrote: post #40

Earlier quoted context omitted.

He was pretty close to being NaN% correct.

To be fair there were a couple of disasters, such as [object Array] and undefined. Feels like the world is hanging on a single thread by now.

You probably meant [object Object] :) Since arrays have their own default toString implementation (its own can of worms that is the basis for JSFuck[0]), you'd have to go out of your way with Object.prototype.toString.call to get [object Array]

[0]: https://jsfuck.com/ relies on Array#toString for casting values to strings

Re: The Birth and Death of JavaScript (2014)

#107

Post by pjmlp »

vips7L wrote: post #99
pjmlp wrote: post #80

Earlier quoted context omitted.

It is basically a revamped Java. Google lost the opportunity to actually make it take off, had they replaced the Java stack with Dart, instead of staying in the Java world and adopt Kotlin. However the Android team was never a great supporter from Dart in first place, hence why you won't find anything Dart on https://developer.android.com .

They should have pushed dart instead of Go imo.

Google never pushed Go, the UNIX/Plan 9 and Oberon folks did, as means to avoid doing C++, with support of their line managers as their 20% project.

Kubernetes was originally written in Java, and Docker in Python, it was thanks to early Go advocacy, that those projects got rewritten in Go, and then they got lucky.

Just like the download server rewrite into Go, that was done by someone from Go team, as part of their advocacy.

Check how many public projects does Google do, outside anything related to CNCF project landscape.

Re: The Birth and Death of JavaScript (2014)

#108

Post by bryanrasmussen »

SonOfLilit wrote: post #78
bryanrasmussen wrote: post #63

Earlier quoted context omitted.

NaN is a standardized dynamic languages datatype governed by IEEE 754, this is not something to complain about as its behavior is part of the official standard and for good reason, as outlined in the standard.

Why dynamic? `NAN != NAN` is just as true in C.

well as I understood it, it was implemented for languages without static data typing although I suppose you could implement it in other languages.

Also I suppose my memory could be pretty foggy as I don't think I've looked at the spec since about 2014.

Re: The Birth and Death of JavaScript (2014)

#110

Post by alerighi »

jdw64 wrote: post #11

JS became a compilation target (and it really did), and back then in the video it was asm.js (that's been deprecated, hasn't it?), but then WebAssembly came along... Seeing it actually being implemented and running natively, it seems his prediction was accurate. I mainly use TypeScript myself, and now with Electron, web technologies are wrapped into desktop apps, so web syntax has even entered computer programs. Peop…

> but it's also the fastest way to support Mac, Windows, and Linux all at once

Is really that simple compared to a normal cross platform web application written in (for example, but there are multiple frameworks) QT?

I mean, sure you have to write JavaScript and not C++, but in the end is that more simple? Maybe to start with yes, but then you get into tooling, typescript, multiple build steps, etc that makes it probably more complex than a old boring QT program in C++. And nowadays with most software not even written by humans, does the argument "but javascript is simpler than C++" really holds?

It's absurd than we could have very performant computers, and we still have the performance of 10 years ago because the added resources in modern PCs gets wasted by programs that need to run an entire Chrome instance to do basic stuff. I mean, open 4 programs that use Electron (Discord, Spotify, VSCode, WhatsApp desktop) on a modern PC and you consumed most of the available RAM just for them.

Post reply on HN