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

111–120 of 144 posts

Re: The Birth and Death of JavaScript (2014)

#111

Post by Zigurd »

derfurth wrote: post #32
frail_figure wrote: post #20

Earlier quoted context omitted.

> but it's also the fastest way to support Mac, Windows, and Linux all at once. Flutter exists too, and supports iOS and Android in addition to the desktop OSes. The dev time is pretty fast too imo. That said, idk how the performance compares to Electron or Native apps. As a small team, optimizing for "actually getting the thing shipped" is so much better than optimizing for speed anyway.

In my experience performance is about the same as native on mobile. On desktop I cannot compare as I thankfully never had to make cross platform desktop apps using native platform SDKs, but Flutter is doing fine. I am a working on a non trivial desktop app, and I am pretty happy about it. Hopefully the desktop story is going improve as Canonical is now leading the Flutter desktop side.

I'm working on an app that's cross-platform on mobile devices. I do builds for macOS as a convenience for my colleagues demoing the app. Pretty much zero effort to add that as a target. I get some benefits out of it too in the form of being able to see how well the UI responds to unusual screen dimensions, running in a resizable window.

Re: The Birth and Death of JavaScript (2014)

#112

Post by cbhl »

I remember watching Gary Bernhardt give this talk live at the Canadian Undergraduate Software Engineering Conference (CUSEC) back in 2014. PNaCl had just come out the year prior, and Google was using it to cross-compile, run, and sandbox OpenSSH and RDP clients inside of Chrome and ChromeOS, and the Mozilla/Firefox folks counter-proposed asm.js as a response.

At the time I just thought it was funny. Now I find it surprising how much of these ideas ended up sticking around.

Re: The Birth and Death of JavaScript (2014)

#113

Post by Zigurd »

greekrich92 wrote: post #66
satvikpendem wrote: post #53

Earlier quoted context omitted.

Flutter is great, still the fastest way to make cross platform mobile apps and you get desktop and web support essentially for free. Performance is very fast as it's all natively AOT compiled machine code without any web views like Electron.

On desktop does flutter have native access to the machine it's running on? Can it talk to printers for example?

I have successfully added AppFunctions on Android to a Flutter app. I figure that's about as hairy a platform-specific feature as it gets. So far nothing has interfered with other platform build targets. I look forward to adding Apple's agentic tool calling interface, too.

Re: The Birth and Death of JavaScript (2014)

#114

Post by ifwinterco »

satvikpendem wrote: post #56

The problem is Wasm is not improving nearly as fast as predicted here. We don't have DOM manipulation so we will still need JS regardless as glue code, or just eschew HTML and CSS altogether and render everything on a canvas as Flutter and some Rust GUIs do but that's a shame to lose the feature set of the web.

The DOM and JS are joined at the hip - the DOM APIs are designed assuming JS is used to access them, and the design of JS and some of its more “unique” features is partly because it was designed for use with the DOM

Re: The Birth and Death of JavaScript (2014)

#115

Post by Zigurd »

pjmlp wrote: post #80
vips7L wrote: post #47

Earlier quoted context omitted.

Darts an amazing language too.

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 .

Google uses Flutter/Dart for their own apps fairly frequently. Obviously not the right choice for the most complex apps. Android system programming and cross platform apps are use cases that are divergent enough that trying to smash them together would result in nobody being happy about the outcome.

Re: The Birth and Death of JavaScript (2014)

#116

Post by throwaway_95283 »

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…

haven't web browsers always been C/C++? they are typescript now? it would seem the fastest way to support Mac, Windows and Linux is 500MB of C++.

Re: The Birth and Death of JavaScript (2014)

#117

Post by moritzwarhier »

sheept wrote: post #106
moritzwarhier wrote: post #65

Earlier quoted context omitted.

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

I intentionally corrected it, because vanilla JS arrays used to behave like this in some contexts, but I'm not even sure about which ones still.

Since the "Array" is a reference to the prototype, I think it might be outdated due to changes in undefined behavior of runtimes when serializing array objects, or logging them.

I'm pretty sure that [object Array] used to be the result of logging an array at some point.

  Object.prototype.toString
always returns the result of

  Array.prototype.join
per spec, afaik, so for an empty array it's the empty string.

Re: The Birth and Death of JavaScript (2014)

#118

Post by throwaway_95283 »

psychoslave wrote: post #92
frail_figure wrote: post #20

Earlier quoted context omitted.

> but it's also the fastest way to support Mac, Windows, and Linux all at once. Flutter exists too, and supports iOS and Android in addition to the desktop OSes. The dev time is pretty fast too imo. That said, idk how the performance compares to Electron or Native apps. As a small team, optimizing for "actually getting the thing shipped" is so much better than optimizing for speed anyway.

https://www.qt.io/development/qt-framework#platforms looks to comply with the stated specifications.

yes, but the unstated caveats for fastest are

"i can't program, i only make CRUD apps"

"i don't write anything that requires computation"

"i do server side rendering on a serverless platform"

in reality rails runs circles around typescript for productivity for CRUD/webapps.

Re: The Birth and Death of JavaScript (2014)

#119

Post by vips7L »

Zigurd wrote: post #115
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 .

Google uses Flutter/Dart for their own apps fairly frequently. Obviously not the right choice for the most complex apps. Android system programming and cross platform apps are use cases that are divergent enough that trying to smash them together would result in nobody being happy about the outcome.

Pretty sure AdWords is built on dart too

Re: The Birth and Death of JavaScript (2014)

#120

Post by pjmlp »

Zigurd wrote: post #115
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 .

Google uses Flutter/Dart for their own apps fairly frequently. Obviously not the right choice for the most complex apps. Android system programming and cross platform apps are use cases that are divergent enough that trying to smash them together would result in nobody being happy about the outcome.

Except for AdWords and Google Pay, which ones?

As far as I am aware, most teams would rather use J2Objc or KMM than Flutter.

Post reply on HN