There's an argument to be made that this [0] (generated via [1]) is not something to be celebrated. But that's just me, not necessarily what the parent poster had in mind.
1,260 karma · joined November 2, 2009
1. I don't have the mental capacity to keep every single function's argument/return shape in my head, or to manually check it every time I make a change. Unit tests can't deliver 100% code coverage in practice.
2. Nor do I want to perform refactorings with stone age tools like s/setFoo/setBar/g. Setting up type information lets my IDE understand which calls to .push() deal with a native Array and which ones deal with my own class, so it can rename the latter ones when I ask. I can also use tools like "Find References" and avoid false positives.
3. I'm not a one-man-band. My coworkers need to deal with this project too, and new developers need to be introduced to it from time to time, and types serve as documentation and guard rails for them much better than jsdoc or regular comments. (This also serves as a significant barrier against using anything more esoteric like Elm, because nobody around would be familiar with it. TypeScript adds just enough syntax on top of regular JS to keep JS users comfortable.)
---
I do use `any` (and `unknown`), I have no doubts that an edge case can crash my app because I didn't validate something, and I never expect third-party code to work flawlessly whether it has types or not. Rejecting TS completely because "but run time loopholes" is throwing the baby out with the bathwater (or to put it in a more hyperbolic way, being an anti-vaxxer because vaccines are not 100% safe from side-effects). TS and types are an additional safety net/force multiplier†, not a silver bullet. (That said, what is a silver bullet? Because I'd sure like one.)
---
† Only applies to a project that has passed its initial rapid prototyping phase. During wild prototyping rides, types can indeed slow you down. But that's really the same debate as RDBMS vs NoSQL.
> For my work I look at horrible code bases, perfectly typed and strictly formatted by tslint.
There is no language that can stop people from producing horrible code.
An example use case: the person writing the HTML ≠ the person writing the selectors. Browser extensions like Stylus, for example. If the HTML author did not bother to add a specific class you need, you have to resort to ugly methods.
In fact, this is a scenario I deal with regularly. I have a Chrome extension for video download sites that scans the current page for metadata (title, performers, release date, etc.) and decorates the download links with `download="…"` attributes, so that I can download a file with a properly formatted filename. I manually adapt this extension to every site I need, and quite often I need things like `a[href^=/model/]` † to distinguish links to performers from other links to get their text content. It's clearly not a situation the site authors worry about, and that's fine as long as I have a way to do this myself.
† This particular selector can be done without jQuery if you don't care about backcompat. In browser extensions, you usually don't. But it's still an answer to your question about when such selectors are needed.
---
Since I'm talking about this, that same browser extension can demonstrate some other complications brought on by React and CSS-in-JS:
1. CSS-in-JS turns class names into unreliable gobbledygook, so extracting metadata means more regex selectors and abominable DOM hierarchy selectors (`section>div>div:first-child>div` because nobody bothers with semantic <h2> or even .title anymore).
2. React makes DOM elements vanish and reappear instead of just hiding them, so that `download="…"` attribute I want to add has to go through a MutationObserver instead of just running once on page load.
In my experience, with jQuery you spend a lot more time making sure each and every event handler puts all UI elements in a correct state, often repeating yourself or calling the same helper functions. With React, all that computation is concentrated in render(), making it easier to reason about. And if you need to add a new UI element, reviewing all jQuery event handlers will again be a lot more work.
Of course, this assumes you are working on a real SPA with a lot of dynamic state, not on a reddit clone where all you need is a reply button to hide/show a textarea and a hidden field to track the parent post id.
The 'Email' field in the profile is not visible to other users. You should add it to the 'About' field.
If I never have to explain <!-- ko if: !condition --> vs <!-- ko ifnot: condition --> again, I'll be a happy man.
Except for cases when it doesn't feel like supporting the standard in question, or it claims their support is sufficient. A recent example could be support for <input autocomplete="..."> [0].
[0]: https://www.reddit.com/r/programming/comments/ar1qj1//egl52w...
Trivia: Shift-Ins actually predates Ctrl-V :-)
---
Come to think of it, is there a definitive guide to HN comment formatting? Implementing a preview feature in [1] would be doable if the markup is documented.
[0]: https://redditenhancementsuite.com/
[1]: https://chrome.google.com/webstore/detail/hacker-news-enhanc...
[0]: https://en.wikipedia.org/wiki/Windows_Metafile_vulnerability
Languages like C and C++ made it readable with debug symbols.
The web stack does the same with source maps. The TypeScript compiler also offers to emit .d.ts files with type information for reuse in other projects.
Those generic use cases are good examples of flexible types, but I have a hard time seeing how
* "I don't know whether the `getMyReplies()` function returns a list of items, an iterator, a non-rewindable generator whose results I need to cache, or a closure with/without memoization" and
* "I don't know whether the singular Reply entity has a field called pid, parent_id, parentId, ParentID, ParentGUID, or parent_message_identifier"
are advantageous to rendering a list of replies.
* UNIX tools don't get updated every week.
* UNIX tools don't get deprecated and replaced every month.
* When UNIX tools do update, the updates don't carry a risk of adding shady code from new maintainers because the original author "got bored lol" and handed the repo over to the first person who asked.
* When UNIX tools do update, the updates don't introduce unvetted and undocumented code that will, for example, start displaying Christmas decorations in your UI on certain dates.
How many UNIX tools actually come in "writing this from scratch is faster than searching for a tool that already does this, so I'll just write my own" size (except for `yes` and such)? Trick question: is trying to install a new UNIX tool similar to this [0]?
1. Generic typehints, for one. Typehinting half the methods as returning a generic `array` is not fun.
2. And that's before you even remember that PHP's array is both a vector and a hashmap, so you need to install a PECL extension or a third-party library to get proper Map/Sequence/etc.
Granted, those technologies are not as widely used and that limit, if absent, would not inconvenience the user as quickly and easily as CPU/memory hogging does.