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

New Features in ES2019

javascript.christmas

Post reply on HN
Print view View original

61–70 of 123 posts

Re: New Features in ES2019

#61

Post by wging »

tiborsaas wrote: post #51
capableweb wrote: post #46

Earlier quoted context omitted.

> fetch API does that for you automatically It does not do it automatically. Even in your example, you call `Response.json()` to do the parsing. If you change that to `Response.text()` it will be text instead. If you don't include the `.json()` call, nothing will be parsed from the body.

I know how it works :) Since it's part of the API getting a response object is pretty effortless, which is a better word than automatic, agree.

That's right, but parsing JSON into a JavaScript object will not give you a date object, which is what OP was referring to.

Re: New Features in ES2019

#62

Post by giancarlostoro »

pythux wrote: post #11

Really liking these new developments! JavaScript is not the horrible language it used to be anymore (in my very subjective opinion). When I started writing JavaScript in 2016 after a Python background I was frustrated every day... Then after some time and learning about which dark corners to avoid, which tools to use, etc. it became quite an enjoyable experience. Nowadays I mostly use a mix of JavaScript and TypeScri…

Honestly if I hadnt gotten into Python and learned some amazing ways to write code I would of never have been as productive with JavaScript as I have been all these years. It was painful at first but over time I have learned the quirks.

Re: New Features in ES2019

#63

Post by vbezhenar »

IgorPartola wrote: post #16

Not ES directly, but you know what I need on an almost daily basis? A JSON date type. It’s obnoxious to have to pass a string back and forth and parse it on either end between server and browser.

I was going to argue with you, that there are plenty of useful types. Temporal types are just one of them and requiring a dedicated syntax might be overkill. But now I thought more about it and honestly temporals are the most frequently used data type for interaction between systems outside of basic ones. So actually it would make a lot of sense. It could be just ISO-8601 literal. Something like `{"date": 2019-12-15, "timestamp": 2019-12-15T23:49:55.123456, "time": 19:57, "timestampwithtz": 2019-12-15T23:49:55.123456-06:00}`. It starts like a number but follows a dash or twocolon which indicates that it's not a number, but a temporal value. Should not be a problem to parse.

Re: New Features in ES2019

#64

Post by Bishonen88 »

pythux wrote: post #11

Really liking these new developments! JavaScript is not the horrible language it used to be anymore (in my very subjective opinion). When I started writing JavaScript in 2016 after a Python background I was frustrated every day... Then after some time and learning about which dark corners to avoid, which tools to use, etc. it became quite an enjoyable experience. Nowadays I mostly use a mix of JavaScript and TypeScri…

Any of the best practices and which tools to use you'd care to share?

Re: New Features in ES2019

#66

Post by proxybop »

gatherhunterer wrote: post #55
topicseed wrote: post #49

I love Javascript and TypeScript, but with all the technologies gravitating around JS, the setup for a project gets clunkier and clunkier. But overall, loving the direction JS is taking.

I hear this a lot, but everything can be handled with a single tool: Webpack. Even a TS project can compile with Webpack and all of its assets, minification and compression needs can be handled in the same file. While you’re at it you can set up a development server with source mapping. Just take an afternoon to learn Webpack and be done with complaining about setup overhead. I set up a multi-stage build for TS Proje…

> take an afternoon to learn we pack

If only it was that easy. The weeks I’ve spent hunting down webpack specific bugs because the plugins don’t always quite work with typescript transformations and source maps...

Re: New Features in ES2019

#67

Post by minimuffins »

mantap wrote: post #28
pythux wrote: post #11

Really liking these new developments! JavaScript is not the horrible language it used to be anymore (in my very subjective opinion). When I started writing JavaScript in 2016 after a Python background I was frustrated every day... Then after some time and learning about which dark corners to avoid, which tools to use, etc. it became quite an enjoyable experience. Nowadays I mostly use a mix of JavaScript and TypeScri…

The difference between JS and C++ is that C++ is addressing a complex problem domain whereas JS is addressing a simple one. So JS can put its complexity budget towards features that improve productivity whereas such features in C++ require huge amounts of complexity. Take for instance anonymous functions in JS compared with lambdas since C++11, the C++ version needs a complicated capture syntax, capability for captur…

Weird that this is downvoted. It's a perfectly plausible point, clearly stated.

Re: New Features in ES2019

#68

Post by ravenstine »

> Optional catch binding

Eh... that's great and all, but why not go the whole way and allow me to just use `try { }` without a catch-block? I'm sure that was part of a conversation somewhere, and I wonder why they chose not to go that far.

Re: New Features in ES2019

#69

Post by goto11 »

ravenstine wrote: post #68

> Optional catch binding Eh... that's great and all, but why not go the whole way and allow me to just use `try { }` without a catch-block? I'm sure that was part of a conversation somewhere, and I wonder why they chose not to go that far.

If it doesn't make any difference if the code inside the try block is executed or not, why even have the code in the first place? What is the use case for a try without a catch?

Re: New Features in ES2019

#70

Post by 11235813213455 »

pythux wrote: post #50
masklinn wrote: post #35

Earlier quoted context omitted.

> I remember when I started I never knew what the "best way" to iterate on things was... for loops? for in? for of? foreach? And it was not obvious which one to use or what were the differences. Possibly aside from the latter (assuming you mean Array#forEach), these are not different "methods with simple behaviour", they're different language constructs with largely overlapping behaviour & use cases.

Sorry if I expressed myself poorly but that is exactly the point I wanted to make. To maintain backward compatibility, new constructs with partial overlap with existing ones are introduced; and this overall increases the complexity of the language. Whereas breaking backward compatibility would allow to re-use existing constructs and change their semantics (I am not saying this would be a better path though).

For example there are 3 String methods to take a substring (substring, substr, slice) (there's even 4th way in proposal: https://github.com/tc39/proposal-slice-notation)

The last added one is slice, and actually simplifies things, with its consistency with Array.prototype.slice, and replace the old ones

I agree it's annoying to keep old methods for backward-comptibility

Post reply on HN