What's New in JavaScript for 2019 • Hacker News Board

Re: What's New in JavaScript for 2019

#61

Post by reverentgeek » Tue, Jan 22, 2019, 9:42 PM UTC

stevecalifornia wrote: post #55

If you want to make programming inaccessible to newcomers, start making special characters that inexplicably mean special things... like # means 'private' when placed in front of a function.

That is a legitimate concern. Even if the person isn't new to programming and is coming from other C-like languages such as Java or C#, there's a good deal of precedence. Just like the "Don't Make Me Think" usability argument, we ought to stick with the conventions that people already know and are familiar with.

Re: What's New in JavaScript for 2019

#62

Post by altmind » Tue, Jan 22, 2019, 9:42 PM UTC

vdnkh wrote: post #19

altmind wrote: post #16

I'm alerted that javascript tends to bloat the stdlib. Most of the features mentioned can be implmented as a external library. This is benefitial for users as they can switch the implenmentation and upgrade versions without waiting for all of their users to upgrade the runtime first. The prime example of javascript unnecessary bloat is fetch api which is mere wrapper for ajax calls, was developed a while ago but stil…

From a performance standpoint it’s way better to have stdlib grow as opposed to JS bundles. Modules aren’t shared within a page so you’d end up with a lot of duplicated code that the user would have to continuously download and parse.

The problem here you can only rely on stdlib when most of your users have runtimes with it. For the browser features, you may never live up to this.

Its worse to forever live with two implementations(native and polyfill) and as large bundles, double the troubleshooting effort and extra support.

Re: What's New in JavaScript for 2019

#63

Post by reverentgeek » Tue, Jan 22, 2019, 9:43 PM UTC

notus wrote: post #23

The proposed globalThis seems like a hacky solution to a bad problem

I agree. It's ugly. I understand it's named globalThis to avoid collision with other libraries and breaking things, but my goodness.

Re: What's New in JavaScript for 2019

#64

Post by z3t4 » Tue, Jan 22, 2019, 9:48 PM UTC

gautamnarula wrote: post #42

dsego wrote: post #34

At this point why not just have browsers run TypeScript natively? Remember the , maybe just put and be done with it.

In my uneducated opinion, I think this is the direction things will go. Typescript will steadily supplant JavaScript and browsers will eventually roll out native support for it, and JS will be relegated to a legacy language.

Having TypeScript support in the browser doesn't make sense as the idea behind TypeScript is to add a compilation step so that type errors can be caught at compilation time. eg. before the code runs.

Re: What's New in JavaScript for 2019

#65

Post by yayana » Tue, Jan 22, 2019, 9:49 PM UTC

scrollaway wrote: post #45

dsego wrote: post #34

At this point why not just have browsers run TypeScript natively? Remember the , maybe just put and be done with it.

What's the point? If you're going to use typescript, you will want to do typechecking. And if you do typechecking, you might as well compile your project properly. I'd honestly rather have browser support less than more and I'm happy with type annotations remaining a language superset. The current typescript situation is actually fantastic and as a python dev, I envy it a lot .

If TS becomes the majority, it seems to me like the browser debuggers could start using types at run time to catch some interesting things that aren't so obvious when compiling the pieces. I.e. help the people who add the final touches to a site check that they have not messed it all up without the project writer needing to decide how many guards to compile in to the project interfaces.

Probably the largest problem I have with modern projects is how unfriendly they are to experiment with on the page, even if there's no intention to prevent it.

Re: What's New in JavaScript for 2019

#66

Post by scrollaway » Tue, Jan 22, 2019, 9:53 PM UTC

zuppy wrote: post #26

westoque wrote: post #12

I might get heat for this but personally I find the JavaScript ecosystem to be a mess. There are so many changes to the language that are done aggressively which I think are done without much thought. For example, the promises API, now we also have async/await. The module system, with require(s), then import/export, and there's browser JS and system JS (node), and npm and now yarn, then your build system, with webpac…

if we’re here, i’ve got a rant about npm. if you have more than a few dependencies, you need to download half of the internet for all the required 3rd party packages. this has security implications too, as i see no way to be able to watch them all, even with a local mirror @downvoters: do you care to add a reply? it’s silly that instead of having a conversation, we’re doing this.

I didn't downvote you but I think you're getting grayed out because it's a tired argument that's been had time and time again. It's just… kinda pointless to have it again.

Yes, the all-too-common super-deep dependency trees are a problem. If you're reasonable about your dependencies though it doesn't happen (my last few JS dependency graphs are pretty similar to my Python ones).

One of the issues is the stdlib and the other issue is a different mindset due to a lower barrier of entry to creating a package. (eg. creating and maintaining a package in Python sucks, so you're less likely to do it for small, self-contained things rather than create a utils.py)

shrugs, I honestly don't know what meaningful change this discussion can lead to. People are generally aware of this, and the problem isn't actively getting worse, so I imagine it'll get better over time.

Re: What's New in JavaScript for 2019

#67

Post by scrollaway » Tue, Jan 22, 2019, 9:55 PM UTC

yayana wrote: post #65

scrollaway wrote: post #45

Earlier quoted context omitted.

What's the point? If you're going to use typescript, you will want to do typechecking. And if you do typechecking, you might as well compile your project properly. I'd honestly rather have browser support less than more and I'm happy with type annotations remaining a language superset. The current typescript situation is actually fantastic and as a python dev, I envy it a lot .

If TS becomes the majority, it seems to me like the browser debuggers could start using types at run time to catch some interesting things that aren't so obvious when compiling the pieces. I.e. help the people who add the final touches to a site check that they have not messed it all up without the project writer needing to decide how many guards to compile in to the project interfaces. Probably the largest problem I…

Hmm, I can't quite see what kind of thing browsers could catch that typescript itself couldn't, since the whole point of types is to be useful at compile-time.

That said I could see some type introspection being useful in the devtools. This is probably already feasible though, as devtools are sourcemap aware. And typescript is written in typescript after all, so it couldn't be that hard to pull in support for it in the devtools, could it? :)

Cool idea!

Re: What's New in JavaScript for 2019

#68

Post by z3t4 » Tue, Jan 22, 2019, 10:00 PM UTC

Noob question: What does static mean in other languages? Is it basically Foo.prototype.bar !?

Re: What's New in JavaScript for 2019

#69

Post by notus » Tue, Jan 22, 2019, 10:03 PM UTC

rinchik wrote: post #40

Klathmon wrote: post #36

Earlier quoted context omitted.

I feel like i'm spamming this link every time the private fields stuff comes up, but take a look at the FAQ, it explains the reasoning behind it and why they didn't go with alternate options (like underscore, private, or others). I was against it at first, but after reading through that document, i'm on their side now. It'll be a small but useful addition in some situations, and it's scope is extremely limited. https…

Thank you for that link, will read it carefully. From the first glance it feels like an attempt to cover mess with a bigger mess: > this is already a source of enough confusion in JS; we'd prefer not to make it worse > Property access semantics are already complicated, and we don't want to slow down every property access just to add this feature. > [private x] in JavaScript this would silently create or access a publ…

Yeah I have to agree with this. I'm getting this vibe from a lot of changes to JS lately. A mess designed to cover another mess and people almost blindly supporting the new mess just because there is some logical rationale for it.

Re: What's New in JavaScript for 2019

#70

Post by zuppy » Tue, Jan 22, 2019, 10:04 PM UTC

scrollaway wrote: post #66

zuppy wrote: post #26

Earlier quoted context omitted.

if we’re here, i’ve got a rant about npm. if you have more than a few dependencies, you need to download half of the internet for all the required 3rd party packages. this has security implications too, as i see no way to be able to watch them all, even with a local mirror @downvoters: do you care to add a reply? it’s silly that instead of having a conversation, we’re doing this.

I didn't downvote you but I think you're getting grayed out because it's a tired argument that's been had time and time again. It's just… kinda pointless to have it again. Yes, the all-too-common super-deep dependency trees are a problem. If you're reasonable about your dependencies though it doesn't happen (my last few JS dependency graphs are pretty similar to my Python ones). One of the issues is the stdlib and th…

ok, that’s fair, thanks. i haven’t participted that much in js related discutions, it’s just frustrating to me and didn’t know that this is pushing some hot buttons :)