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

It’s time to free JavaScript (2024)

javascript.tm

Post reply on HN
Print view View original

381–390 of 393 posts

Re: It’s time to free JavaScript (2024)

#381

Post by Vinnl »

lelanthran wrote: post #302
Vinnl wrote: post #233

Earlier quoted context omitted.

So then the user gets a type error in their face instead of the page loading? That doesn't really sound better than the developer getting that error while writing the code, which is what TypeScript currently does.

> So then the user gets a type error in their face instead of the page loading? The alternative is not "User sees no error", it's "user sees the error at runtime". In which case, yeah, having the user see the type error is vastly preferable to having the user see a runtime JS error.

In my mind, the alternative is running TypeScript while writing and at build time. Type checking at runtime is at best redundant, and at worst an excuse to skip type checking and have it blow up in the users' face.

Re: It’s time to free JavaScript (2024)

#382

Post by collinmanderson »

Anarch157a wrote: post #276
collinmanderson wrote: post #203

The last time this was brought up, "WebScript" was mentioned as a possible alternative name. (Like WebAssembly, WebSockets, WebRTC, etc.) https://news.ycombinator.com/item?id=45297066

My personal favourite is "JayScript".

I like it. JSON’s father.

Re: It’s time to free JavaScript (2024)

#383

Post by morshu9001 »

Alifatisk wrote: post #376
morshu9001 wrote: post #336

Earlier quoted context omitted.

Dart looks ok, but looking at the Dart equivalents of JS examples like {foo: 1}, I'd rather use JS

There is sadly no equivalent to {foo: 1} in Dart. This difference stems from Darts class based object model while JSs is, as you probably know, prototype based

That's my issue with this, I like the prototype system. It's very convenient for this kind of use case.

Re: It’s time to free JavaScript (2024)

#384

Post by opem »

GoblinSlayer wrote: post #124
heretia wrote: post #99

Earlier quoted context omitted.

> probably more people are aware of JavaScript than Java at this point All the same, I probably get as many calls from recruiters to fill Java positions as I do JS positions. I've never used the former, and explaining it is always awkward!

For normal people Java is a short way to say JavaScript.

You mean ab-normal, I guess

Re: It’s time to free JavaScript (2024)

#385

Post by brabel »

nunobrito wrote: post #221
xxs wrote: post #201

Earlier quoted context omitted.

>I can't imagine writing anything of substance primarily in groovy. That's solely based on a poor imagination, not trying...

Have to agree with the previous person. Never saw a relevant project made from Groovy. Even with Beanshell I've included it a few times in other projects for basic scripting/customization within the app but groovy? Never in 15 years to now.

We use the Spock Framework for testing. It's the best testing framework in the JVM, no joke.

Re: It’s time to free JavaScript (2024)

#386

Post by brianhama »

gosub100 wrote: post #299
karel-3d wrote: post #35

They now have GoFundMe where they are soliciting donations for a discovery phase of a patent trademark cancellation request. They have just 50k USD out of 200k USD they are raising. (No idea if that's appropriate; from the outside, it seems like a lot of money, but also they are fighting Oracle which has unlimited money, so, yeah) For some reason it's not linked in the page itself. https://www.gofundme.com/f/help-us-…

Side question: can the CEO or sole proprietor of a corporation/small business/ nonprofit litigate pro se on behalf of their company? I know you can do this when acting as an individual, but if a business is too poor to afford representation, can they "wing it" as a last ditch measure? Or is it checkmate at that point? If possible, I would like to see the good guys in these cases go down fighting, and try to delay pro…

Only if the owner happens to be a lawyer. Otherwise it would be the illegal practice of law.

Re: It’s time to free JavaScript (2024)

#387

Post by lelanthran »

Vinnl wrote: post #381
lelanthran wrote: post #302

Earlier quoted context omitted.

> So then the user gets a type error in their face instead of the page loading? The alternative is not "User sees no error", it's "user sees the error at runtime". In which case, yeah, having the user see the type error is vastly preferable to having the user see a runtime JS error.

In my mind, the alternative is running TypeScript while writing and at build time. Type checking at runtime is at best redundant, and at worst an excuse to skip type checking and have it blow up in the users' face.

> In my mind, the alternative is running TypeScript while writing and at build time.

Right now, sure.

But if TS is supported natively in the browser, wouldn't your editor highlight the errors as you type? In which case the chance of deploying a broken TS file to the browser is minimal - you'll have to go out of your way to do so, like writing the TS file in plain notepad.

To go even further, having TS supported in the browser does not mean that you are forced to abandon your build step(s). You are still free to run a build step that either:

1. Does the full compilation to JS, and that's what gets deployed.

or

2. Just lints the file, and has the original TS file deployed.

Nothing in "Native TS in the browser" enforces a no-build-step dev process; it just makes it optional.

There's also the fact that, if JS is no longer the target (either browser-byte-code or native-code will be the target), then type-checking can be improved even further because there will be no requirement to allow things purely due to JS compatibility.

Finally, there's an awfully large number of optimisations that can be done if JS is not the target and native-code is.

I'm not seeing any downside here.

Re: It’s time to free JavaScript (2024)

#389

Post by Vinnl »

lelanthran wrote: post #387
Vinnl wrote: post #381

Earlier quoted context omitted.

In my mind, the alternative is running TypeScript while writing and at build time. Type checking at runtime is at best redundant, and at worst an excuse to skip type checking and have it blow up in the users' face.

> In my mind, the alternative is running TypeScript while writing and at build time. Right now , sure. But if TS is supported natively in the browser, wouldn't your editor highlight the errors as you type? In which case the chance of deploying a broken TS file to the browser is minimal - you'll have to go out of your way to do so, like writing the TS file in plain notepad. To go even further, having TS supported in t…

Yeah that's kinda the point; you get all that, unless you don't run the build-step/in-editor dev process. And the only reason to make that step optional, is to not run it, which is a worse experience.

So I'm not necessarily saying it's a bad thing, it's just that I don't see the point. And given that there's the major downside of having to go through the standards process, both now and in the future, which will likely involve breaking changes and making it harder to update, I don't see it happening. (Edit: I should add that I do think the "types as comments" proposal makes sense. I do see the advantage of being able to run TS code without a build step. It's just the part where we'd throw an error in the user's face that I don't see providing value to anyone.)

I do think TC39 is progressive enough to be OK with changes to JS if those would allow TS to have more effective type checking (as long as they're backwards compatible, of course, which would also be the case if TS got incorporated into JS), so I don't think it's necessary for that.

Performance improvements enabled by optimisations would be nice, but I believe I heard that no major gains would be expected there, especially compared to something like WASM.

Re: It’s time to free JavaScript (2024)

#390

Post by lelanthran »

Vinnl wrote: post #389
lelanthran wrote: post #387

Earlier quoted context omitted.

> In my mind, the alternative is running TypeScript while writing and at build time. Right now , sure. But if TS is supported natively in the browser, wouldn't your editor highlight the errors as you type? In which case the chance of deploying a broken TS file to the browser is minimal - you'll have to go out of your way to do so, like writing the TS file in plain notepad. To go even further, having TS supported in t…

Yeah that's kinda the point; you get all that, unless you don't run the build-step/in-editor dev process. And the only reason to make that step optional, is to not run it, which is a worse experience. So I'm not necessarily saying it's a bad thing, it's just that I don't see the point. And given that there's the major downside of having to go through the standards process, both now and in the future, which will likel…

> And the only reason to make that step optional, is to not run it, which is a worse experience.

Yeah, but it's an optional "worse" experience.

IOW, for those people who think it's a better experience (because there is no build step), they can opt into it. For those who think it's a worse experience, they can continue using a build-step.

Nothing changes for those who want a build-step.

(I agree about the standards process thing)

> Performance improvements enabled by optimisations would be nice, but I believe I heard that no major gains would be expected there, especially compared to something like WASM.

If TS is compiled in the browser, then it can be compiled to WASM, not to JS.

It's only when TS is compiled on the server that it has to be compiled to JS.

If the browser support TS natively, the compilation target would not be JS (which is what makes the resulting code slow), but either WASM, or naive code.

Post reply on HN