neurotrace · HackerTrans

neurotrace

no profile record

comments

há 4 anosdiscuss

I'd love to see some performance metrics and if there are any guard rails against circular dependencies.

há 4 anosdiscuss

I'm a fan of using the extensions the author mentioned when I'm exploring a problem space. I scaffold out the overall design for the problem in terms of modules and functions so that the code reads correctly, type checks, and works for an extreme subset of inputs. Anywhere that I haven't actually implemented the real solution I put in a "NO-MERGE" comment. Then when I feel that I've solved the problem at that scale, I can go through all of my NO-MERGE comments and implement them correctly. As the name implies, these are never merged in to main/master. They just act as bookmarks which should be obvious when reviewing my changes.

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.

há 4 anosdiscuss

> Why would you be worried about vendor-lock if you haven't built anything?

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

há 4 anosdiscuss

> why is NPM so uniquely absolutely horrible?

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/

há 4 anosdiscuss

If JS had no effect on the experience of the page (or the loading of it) then no one would write it. Personally, I don't generally mind running a bunch of JS but I understand why people don't. I use both the modern web and Gemini

há 4 anosdiscuss

I've gotten so used to seeing variants of Wordle that I read "Redditle" and immediately thought it was some sort of Reddit-based Wordle

há 4 anosdiscuss

You should check out Gemini[1]. That's basically how it works.

[1]: https://gemini.circumlunar.space/

há 4 anosdiscuss

You're right. Lifting a coffee cup with poor ergonomics isn't going to cause any injuries. Typing for hundreds of hours over many years in a poor position can lead to problems such as RSI.

há 4 anosdiscuss

Good point. I have always run integration tests with Postgres etc. and have found value in it. I do think that you should have a substantially smaller set of those sorts of tests though.

há 4 anosdiscuss

Not OP but I avoid default exports unless I need to do a lazy import. For me, there's a few reasons: consistent naming, easier importing, encourages importing what you need, avoids weird situation where you do both a default and named import.

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.

há 4 anosdiscuss

> Finally, in terms of organization, I want things to be organized by function, not by feature.

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

`effects` basically holds your business logic, `ui` contains section specific components and exports the top-level component via `ui/index.ts`, `thing.route` hooks up the route to state management, `index.ts` provides a bundle for hooking up the effects to your effect system and the route component itself. The `name.type.extension` naming scheme clears up the tab name confusion problem. Maybe I should write my own article about this ;)

há 4 anosdiscuss

I'd argue that you should have thorough unit tests for each service to ensure that they always respect their public API. Additionally, in a monorepo you can share type definitions so regardless of the service, you know for sure that you're using the right API. If all of that is in place then you can test the integration by just mocking out those services rather than testing their API n times.

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.

há 4 anosdiscuss

Absolutely. I recently dropped in to a job where I was led to believe I'd be spending most of my time architecting applications but I've spent most of my time on ops stuff. Every engineer is expected to have more than a working knowledge of AWS, Terraform, and Kubernetes. I don't know how anyone gets anything done

há 4 anosdiscuss

> And in the next few sections it includes someone who wants to build on the proposal including using type hints to optimize code.

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.

há 4 anosdiscuss

One of the benefits of TypeScript is that it literally is just JavaScript plus some. You can literally run `tsc` and it will spit out JavaScript written the same way as you wrote it but without any of the types. The only things that might look out of place is things like enums or decorators but you can choose not to use them.

há 4 anosdiscuss

> Considered a mistake by whom?

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...

há 4 anosdiscuss

I hear what you're saying but I'd rather not waste even those two hours ;)

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)

It's subtle and not super important but it makes me happy.

há 4 anosdiscuss

For better or for worse, features of TypeScript that generate code (like enums) are generally considered a mistake. I assume part of the idea here is that people would aim to target this particular subset so they can avoid compiling while in development and as such people would move away from those features. I like enums but you can get most of the same benefits with

    type RGB = 'red' | 'green' | 'blue'

há 4 anosdiscuss

The comment was supposed to explain monads by common usage rather than as a mathematical notion. Prolog is not a commonly used language by us blue collar programmers. I feel I have a grasp on monads and yet that explanation meant little to me given my limited experience with Prolog.

há 4 anosdiscuss

Unpopular opinion here: the more I use Vue, the more I realize that it started off doing things differently because it thought it was smarter than more established frameworks. Over time, you're seeing it copy a lot ideas from other systems because they're actually hard earned lessons. Vue is the manifestation of the frontend hype cycle. There's no reason to use it over something like React which is much better supported