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

Just Say No to JavaScript

infoworld.com

Post reply on HN
Print view View original

81–86 of 86 posts

Re: Just Say No to JavaScript

#81

Post by lproven »

coolcoder613 wrote: post #77
lproven wrote: post #59

Earlier quoted context omitted.

> What about dynamic websites? An exact example of the kind of thing I'd like to get rid of. The UK PC vendor Elonex had the first ever webmail system I saw, called HTMail. It was impressive but it was a private in-house tool to give remote workers email access without needing their own machine with an email client. Wrong sales model. It the was followed by the indie HoTMaiL, based on NetBSD servers I think, which ha…

These things don't have to be bloated. For example, I wrote a web chat once, called minchat (minimal chat) [0]. The frontend is written in plain HTML, CSS and JS, totalling ~5kb. The backend is written in Rust. There is room for programs that do not need to be installed. Examples are Flash, Java applets, and Javascript. Personally, I think some sort of UI thing based on WASM might be the way to go, but that's just my…

> some sort of UI thing based on WASM might be the way to go

Oh dear hypothetical deity, please no!

I can best respond by copying my own response from another place:

Do you know Greenspun’s tenth rule?

https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule

It was about Lisp, so it’s an ancient thing now, but it still has truth.

As far as the Unix/Linux/xBSD world goes, it can be generalised like this:

Level 1: Any sufficiently complicated [container or VM management system] contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of Plan 9.

Level 2: Any sufficiently complicated [bytecode VM or runtime environment] contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of Inferno.

Wasm to me still smells very much like a second-hand, poorly-conceived, half-assed version of Dis.

> There is room for programs that do not need to be installed.

Sure there is room. But is this a desirable thing? Is it worth the price in inefficiency and insecurity?

If it is, and I am not 100% convinced of that, then design it right into the OS from the outset. Any effort to bolt it on later will be fatally flawed.

Re: Just Say No to JavaScript

#82

Post by greener_grass »

benfortuna wrote: post #67
greener_grass wrote: post #62

JavaScript is a very capable language. It has better functional programming support than Java and Python. It has fewer footguns that C++. You can start with a scrappy prototype then gradually add type-checking later. Of the mainstream languages, it's actually one of the better ones!

>It has better functional programming support than Java and Python. Sources - or just an opinion stated as fact?

JavaScript lambdas are better for FP than those in Python because they can be on multiple lines.

If going untyped JS, then you don't have the same restrictions as Java.

If going typed, then the TypeScript type-system is more powerful than Java's.

Re: Just Say No to JavaScript

#83

Post by gr4vityWall »

jraph wrote: post #16
glutamate wrote: post #6

The author never actually says what is so wrong with JavaScript. I think it is quite a good dynamically typed language, and it certainly has some very high-performance implementations. If you don't like it, just use something else? > Ultimately, JavaScript was the right thing at the right time. It ended up being folded, spindled, and mutilated to serve purposes that it isn’t well suited for Counterpoint: many quirks…

> The author never actually says what is so wrong with JavaScript The lack of explicit typing. The author argues against untyped code, and for using typescript instead of javascript to get types.

> The author argues against untyped code, and for using typescript instead of javascript to get types.

Considering how much of the article was about typing and not specific to JS itself, "Just Say No to Dynamic Typing" would've probably been a better title for readers. It would likely get less clicks, though. :')

Re: Just Say No to JavaScript

#84

Post by gr4vityWall »

prmph wrote: post #10
bambax wrote: post #3

This is a plea to use TypeScript instead of JS. Why not. Strong typing is certainly great. But the reason I don't use TypeScript isn't any of those listed: it's because it needs a compilation step, and I don't want that.

With runtimes like Bun and Deno (and lately Node itself), you can run Typescript directly with pretty much zero config. There is transpilation behind the scenes, but the time that takes is minimal. I personally switched to Bun, and could not be happier. My build toolchain is quite simple now. I run the Typescript compiler to just type check my code, and use Bun to actually run it. For bundling, I use esbuild.

If you don't mind me asking, is there any particular reason you're not using Bun to bundle it?

Re: Just Say No to JavaScript

#85

Post by jraph »

gr4vityWall wrote: post #83
jraph wrote: post #16

Earlier quoted context omitted.

> The author never actually says what is so wrong with JavaScript The lack of explicit typing. The author argues against untyped code, and for using typescript instead of javascript to get types.

> The author argues against untyped code, and for using typescript instead of javascript to get types. Considering how much of the article was about typing and not specific to JS itself, "Just Say No to Dynamic Typing" would've probably been a better title for readers. It would likely get less clicks, though. :')

Fully agree, "Type your JavaScript code" (pun initially not intended) would have been better :-)

Re: Just Say No to JavaScript

#86

Post by prmph »

gr4vityWall wrote: post #84
prmph wrote: post #10

Earlier quoted context omitted.

With runtimes like Bun and Deno (and lately Node itself), you can run Typescript directly with pretty much zero config. There is transpilation behind the scenes, but the time that takes is minimal. I personally switched to Bun, and could not be happier. My build toolchain is quite simple now. I run the Typescript compiler to just type check my code, and use Bun to actually run it. For bundling, I use esbuild.

If you don't mind me asking, is there any particular reason you're not using Bun to bundle it?

I wasn't sure the Bun bundler was powerful enough to handle my needs. Bundling is a hard thing to get right, and I tried many, many tools and configurations over the years before settling on esbuild.
Post reply on HN