On personal projects? babel-preset-stage-0 #yolo
Ask HN: If you targetting ES6 by default, how did you rationalize that choice?
51–60 of 62 posts
Re: Ask HN: If you targetting ES6 by default, how did you rationalize that choice?
#52Not to nitpick, but the word "rationalize" usually has a negative connotation — to rationalize something is to attempt to justify/explain something that wasn't a rational choice to begin with [1]. In short, you're implying that people's decision to use ES6 wasn't based on a conscious, analytical decision.
If that's not what you meant, perhaps "justify" would be a better word to use. Or maybe just: "Why?"
Re: Ask HN: If you targetting ES6 by default, how did you rationalize that choice?
#53I'm using Typescript. The amount of bugs it catches (e.g. undefined/null errors and unexpected string/number bugs being the biggest ones) makes it more than worth it.
Next stop: Purescript :-)
Re: Ask HN: If you targetting ES6 by default, how did you rationalize that choice?
#54How would you rationalize not using ES6?
Polyfills add a ton of size. https://www.youtube.com/watch?v=L3JJ8qSIg2k
https://github.com/babel/babel-preset-env/ should help with this to remove the polyfills that are already supported, and with some future work to remove polyfills are unused.
Re: Ask HN: If you targetting ES6 by default, how did you rationalize that choice?
#55I'm using Typescript. The amount of bugs it catches (e.g. undefined/null errors and unexpected string/number bugs being the biggest ones) makes it more than worth it.
Next stop: Purescript :-)
Are there any good examples of things you can do in Purescript you can't do in Typescript? I'm finding the latter a good compromise of not going against the grain too much while getting a lot of the type safety I'd expect from a functional language.
Re: Ask HN: If you targetting ES6 by default, how did you rationalize that choice?
#56Earlier quoted context omitted.
Next stop: Purescript :-)
Are there any good examples of things you can do in Purescript you can't do in Typescript? I'm finding the latter a good compromise of not going against the grain too much while getting a lot of the type safety I'd expect from a functional language.
You can't do anything extra since ps compiles to is anyway. However you can get all of the advantages of a powerful type system, and far more compile time guarantees.
Re: Ask HN: If you targetting ES6 by default, how did you rationalize that choice?
#57Earlier quoted context omitted.
Are there any good examples of things you can do in Purescript you can't do in Typescript? I'm finding the latter a good compromise of not going against the grain too much while getting a lot of the type safety I'd expect from a functional language.
You can't do anything extra since ps compiles to is anyway. However you can get all of the advantages of a powerful type system, and far more compile time guarantees.
Do you have examples of compile time guarantees I mean?
Re: Ask HN: If you targetting ES6 by default, how did you rationalize that choice?
#58By not caring about IE11?
You simply have to ask yourself, who do you want to sell your stuff to.
If you got a rather technical audience for example, chances are hight that most of them are using current browsers. So you simply develop for them and get a very simple build process, which eliminates many potential bug sources.
If you want to sell to Siemens, Bosch, Daimler. Chances are hight that they use IE11.
You can also start building for current browsers and if too many people complain or you get the feeling that you lose too much users by ignoring IE, you simply add Babel or something.
Re: Ask HN: If you targetting ES6 by default, how did you rationalize that choice?
#59Earlier quoted context omitted.
You can't do anything extra since ps compiles to is anyway. However you can get all of the advantages of a powerful type system, and far more compile time guarantees.
Do you have examples of compile time guarantees I mean?
Sure
* Your values wont be null. So if you have a type say Object, and a value x of type Object. x will never be null. If in some cases you need values that can be something, or nothing, there is a "Maybe a" type and an "Either a b" type (often used for errors, i.e. it is either an error of type a or a result of type b). This gives you a lot of control and expression around things that might not have values.
* Functions have no side effects. You define a function and it has inputs and outputs but it wont go off and do something else. You can be sure that your functions aren't modifying global state, navigating to new urls etc. even without inspecting the functions they call, and the functions they call.
How does anything get done? Well the desired effects are returned as data. And you can tell by the type what kinds of effects it can produce, and what it can't.
Now I spend a lot of time on C# legacy code thinking 'ah a public property, great who is calling that, what is this function calling, OK a,b,c,d. Now what does a call, ok a1 a2 a3 a4. Ok they look OK now what about b etc. Lots of detective work that is not needed in Haskell/Purescript because the type sigs tell you almost everything you need to know from an architectural point of view about what is going on, because there are no side effects of functions beyond producing data to be consumed.
Re: Ask HN: If you targetting ES6 by default, how did you rationalize that choice?
#60Hello! I assume you are talking about we development. As a developer, the new versions of EcmaScript include good features that make easier the development of our applications. Also, ES6 is not a beta, it's a new version of the language. We are talking about frontend, so the execution environment of our application is unknown. However, the benefits of using the new features are big. For me, the most important one is…
"With the new versions of ES, my code is more independent from external sources." What about all of those external sources brought in to support building\transpiling\source map generation\whatever?
I consider Babel a trusted source. I prefer to transpile the code by Babel instead of using 15 libraries developed by one person. Also, I can remove some transpilation plugins as soon as the browsers implement it