I think this is obviously a useful tool and yet I worry that JS is going to end up in the C++ hole -- too much syntax for most people to remember, having to carve out practical subsets for readability.
const [,, { name }] = props;
const { $ } = window;
[1]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
But alas, no one ever listens in JS. They just add more and more shit until things are unrecognizable.
People hate plain JS so much, that they’d rather mutilate into the language they prefer, and people are coming from every corner of programming with every type of preference (pun).
One of these days I’m going create a barbarian horde of JavaScript developers and inundate another language, maybe Java, maybe Ruby or Python, and just vehemently insist that they must change their idiomatic style to that of Javascript. Let’s see how they like it.
Anyone know why we have 30 imports at the top of each file like it’s Java? Where did that idea come from? Excessive types, huh? Since when? Have mercy on us, please.
Edit:
These were the welcome and necessary changes IMO:
JS just really needed Classes as syntactic sugar for the odd way we replicated it with prototypes. That and the fat arrow (because binding ‘this’ was cumbersome), along with a basic import statement. Destructuring I can live with. Async/await was also necessary. We really didn’t need shit else.
Small exception:
I’ll make a veery small exception for a minimalist type system, or in other words, only 10% of typescript. I’ll take just the ‘Type’ and that’s all.
Last note:
Coffeescript did a better job synthesizing JS with ideas of other languages compared to ES6 honestly. Sometimes you have to think about how things mix/fit rather than ‘oh this language has it and JS doesn’t, so let’s add it’.
And JS codebases are so much larger than in 2003 that the old idiomatic style is just unproductive.
I’m advocating for a tighter, more minimalist language. It’s not what you put in, it’s what you leave out, remember?
What parts of TypeScript are you finding would impart more value by having been left out? For example, I find it extremely expressive, and I have gotten huge value out of things like accessing return types of functions, aliasing the non-nullable types in a union type, creating sub-types of massive JSON structures via `subtype = MyType["mySubField"]`, Partial/Pick, Exclude/Omit, ... What things have you seen that you don't understand the usage for?
Final question: what is the most sophisticated UI component you have ever implemented? For example, I regularly implement what are sometimes referred to as "dataflow editors", so maybe this helps explain why I see value in the more niche sides of TS while you come in and decry the construct entirely
Maybe, maybe not. But to entertain you, if the breadth of Typescript solves your niche needs, do you believe most UIs require that same exhaustive usage? Because that’s what’s happening, I’ve seen very simple things overusing it.
I don’t have much more to say about this, but happy to hear your last word.
> Do you believe you could not write that UI
No, I wrote these UIs in bare JS and React before, using class-based components and old react state or mobx. I also maintain a library of components because I generally write multiple UIs simultaneously, which of course can use the same building blocks. Since React Hooks & TypeScript, my component library lost about 40% of the LOC (after adding type definitions), looks much prettier, and is infinitely more discoverable with type annotations and autocomplete on everything.
So, do I need it? No, you arguably never need type systems. But the developer experience is an order of magnitude smoother. I option-click into any component when I need to understand its type interface, and I don't need to read any code to do that! I also can seamlessly use graphql-codegen.
But maybe more to the point:
> I’ve seen very simple things overusing it
This is true of every construct, ever, do you not think? People are not inherently good programmers.
Ultimately, I admit that TypeScript and JS have design flaws and non-minimalist features that you can attribute to "dumb evolution" (i.e. people adding features here and there to JS, TS trying to ensure all sorts of JS are covered, TS trying to make sure you can handle all existing types of JS with TS, etc.). However, given the context being that JS & React/JSX are the dominant UI language for web, TS solves this use-case cleanly and with a great level of expressiveness. It is huge and can be overwhelming, but it's important to remember you don't need to use any of these things, and there isn't really. any sort of interop-gulf around TS either (i.e. someone exports a type, you can interact with it, no questions asked).
So, is it graceful from an idealist perspective? No, I concede this. However, it is a tool I would never again turn away from, and while I wouldn't necessarily say it enables me as an individual to do new things, I think it makes it possible to program ideas of high complexity and allow others to work with it much more easily than just JS, which enables me as a team member to boost my teammates.
I worked on a team that happened to be starting on a cross-platform React Native app that needed to have its business logic able to be re-used on a couple other platforms that weren't well-supported by React Native (or React), but did support JS well enough, when we decided to trial TypeScript. The team had done a bunch of "apps" in React and a couple in React Native without TypeScript, before this.
TypeScript made things so much nicer. It cut necessary communication overhead during development down to almost nothing. Turnaround on platforms that were slow to deploy to was a non-issue because things almost always worked on the first try. Navigating the codebase was downright pleasant. Refactoring a library that was used by multiple platforms, a breeze. Simply excellent.
All we should have are primitive types like object, number, string, boolean, undefined. Anything else should just define a shape/interface of an object, but no "type" that can be inherited.
In that case, as you say, 90% of Typescript could go away and be relatively straight forward.
> JS just really needed Classes as syntactic sugar for the odd way we replicated it with prototypes.
Depends on if that's actually odd. In my opinion, we should avoid prototypes most of the time, so it's strange in retrospect that we layered a cumbersome OO construct on top of it without any of the benefits other languages have like being able to change the constructor/initializer method after class construction.
> We really didn’t need shit else.
Yep. Sadly the older I'll get the more crystalized that realization will become and the more frustrated I'll be at a world that thinks more is better.
Shit like:
const [,, { name }] = props;
function foo({
quux: {
foo: {
bar: {
baz: [first]
}
}
}
}) {
console.log(first);
}
In the 7 years or so that destructuring assignment has been available, I've never once seen the 'empty destructuring' in your first example. (And if I did, I'd most likely tell someone to just do `const { name } = props[2];`. The second example is a bit silly- if you're using jQuery that much, autoprovide it using a transpiler and be done with it.
My guess is that your org just can't be bothered to care that much about your frontend, so they slap something together that's difficult to maintain, and then blame the language, execution environment, or community for poor results.
For example, types vs interfaces in typescript - they can be used interchangeably in many cases, and not in a few other cases. [1]
Let's KISS, not over complicate for the sake of more features that may be negligible in value. And let us especially not introduce features that can overlap.
[1] Example: "A class can implement an interface or type alias, both in the same exact way." - https://stackoverflow.com/questions/37233735/interfaces-vs-t...
C++'s syntax problem, to my mind, is not that it's excessively large, but that it's excessively clever and error-prone, and sometimes not very uniform. It's hard for humans to parse.
This proposal does not introduce any special cases, it adds one (or two, if |?> is also accepted) very clearly defined operators, proven by practice. It makes parsing things by humans easier.