neurotrace
Personally, I try not to commit any TODO comments. They're sort of like warnings. Unless you're religious about clearing them out, they're just going to build up and be ignored.
When else would you worry about lock-in? The early stages of a project involve setting up the foundation. If you build your foundation on vendor-specific tech, you've just locked yourself in or signed yourself up for a very painful transition in the future
I'm not sure that it is. I think it's a numbers game. I've read* that npm is the largest repository in the world. More actors means more good and bad actors.
* Taken from this link. Old article and I'm not sure what the original data source is: https://www.linux.com/news/state-union-npm/
Consistent naming: since I named the exported thing, that's what the consumers will call it as well unless they go out of their way to do `import { X as Y } from '...'`. This is useful because it helps ensure all consuming code looks similar at least in it's usage of modules. More familiar code is easier to read and reason about. It's also useful for looking up usages of something. I know I can run $IDE's version of "Find Usage" but sometimes it's easier to just Ctrl+Shift+F > X.
Easier importing: If I have something exported as X then I go to a module that isn't using it and I type X, my editor will suggest I import it from the appropriate module. This _can_ work on default exports but only if you use the same name as was used internally at the point of definition. That kind of defeats the benefit of default imports where you can use whatever name you want without hassle and it's your responsibility to make sure you match the names correctly.
Encourages importing what you need: when you default to named exports, you default to pulling in the bare minimum to do the job. Consider the opposite case. Someone imports some monolithic chunk of code as a single object then does `library.thingIWant` with a bunch of different things. Now you've got a larger possible space to look at when trying to load all of the context of a file in to your head. This is also useful for tree shaking. Assuming you've written your code in a well-defined manner and are using a smart build system, it can more easily eliminate dead code because it knows you never import certain pieces of a module. This applies to both your code and code from third-parties.
Both default and named imports: This is common when working with React. You'll see `import React, { useState } from 'react'` or similar. I don't have a rational answer for this but it rubs me the wrong way.
I found this super surprising. I much prefer doing things by feature than by function. Where it goes is a function of which page/view/route it's on. If it's a general purpose component that is used on multiple pages (like `Button`) then, sure, it goes in `src/components`. Otherwise, it goes in `src/routes/app-section/components`. Truth be told, I've taken to doing a setup like this:
src/
- routes/
- app-section/
- effects/
- some-action.effect.ts
- ui/
- app-section.component.tsx
- index.ts
- some-component.component.tsx
- app-section.route.ts
- app-section.types.ts
- index.ts
If you're in an environment where you have limited/absence of type checking then you're right. In my experience, most problems that come from the integration of networked services come from not properly accounting for all possible responses. You're expecting to get a 200 response and a field of `x` but you got a 204 so the response is empty. That sort of thing.
This changes literally nothing about the JS language. JS engines already attempt to determine the types of things to optimize the code they generate. Type annotations would just allow them to make more aggressive optimizations.
The developers of TypeScript. TypeScript aims to avoid adding anything to the runtime as a result of the type system[1].
> It would change nothing to the already complex build pipelines JS developers are already mandated to use for production.
You're right, it wouldn't change anything when you're building for production if you're doing things right. It would mean that you don't have to repeatedly compile your code while you're developing it though.
> What Typescript should do as an alternative is better support for JSDoc type analysis.
If you read the proposal you'll see they explain why expanding JSDoc is not ideal. Personally, I wrote a lot of JSDoc back before TypeScript and now I don't want to touch the stuff. TS is much more ergonomic and expressive.
[1]: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Desi...
I agree with what @erikpukinskis said but I'll also add that I just like the way they read. It immediately tells me that there is a limited number of potential values that can be put in a place. If I see some arbitrary string then I have to wonder, if only briefly, if any arbitrary string can be plugged in there.
// What does addTask take? Days of the week?
// Time-sensitive identifiers like you'd see in moment.js?
// I guess I'll check the definition or mock out a call to see
addTask('Sunday', newTask)
// vs.
// Ah, it takes a day
addTask(Day.Sunday, newTask)
type RGB = 'red' | 'green' | 'blue'All that is to say that RSS still works. What's missing is the original content creators of the early RSS world. Nowadays, most people create small, easy-to-write, easy-to-consume content in one of the walled gardens since the notifications, interactions, and network are all included for them.
I sincerely doubt we'll ever see that. First off, Venmo has already tried to apply the social media formula to transactions. I don't know of a single person who reads their Venmo feed just for fun. Next, most transactions are boring and not worth sharing. "John bought toilet paper and Q-tips. [Like] [Retweet]".
You state that the move to hyper-publicity that we've already seen hasn't reached it's peak for usefulness and yet there are already widespread conversations about the dangers and pain that this hyper-publicity has caused.
If we reach a future where people are "proud" of their transactions and are sharing them everywhere then we've made a horrible mistake.
When you write anything substantial you end up with class name soup. The answer to this is to use `@apply` which is literally just a normal CSS class with extra steps.
The new vernacular just means that users have to learn Tailwind language rather than proper CSS.
CSS modules solve the main problems that Tailwind attempts to solve. The other things are solved with use of CSS variables.
The only thing that I find useful in Tailwind is the responsive design classes. Being able to do `md:<some other style here>` is pretty cool.
To me, Tailwind seems valuable to newer engineers because they feel like they don't have to learn CSS. They learn "Tailwind." It's like all those people who would say "I don't know JavaScript, I know jQuery." Like jQuery, there are benefits in having a unified language especially when you're newer. I believe that a better solution to styling is inevitable (my latest favorite heavily uses CSS variables). I do not believe Tailwind is the best way forward.