neurotrace

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

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.

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

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/

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

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

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

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

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.

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.

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.

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
        

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.

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

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.

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.

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

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)

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'

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.

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

Children can learn Monopoly fairly quickly. To me, that sounds pretty simple. Buy property, get money when people land on it, get more money if you have more house/hotels. That's just about it

I've had my laptop for a while now and haven't noticed any build quality issues. It definitely feels nice and light but it seems sturdy enough. I'm not in the habit of dropping my laptop on the ground but I do chuck it on to the bed from time and to time and it doesn't seem any worse for wear.

I think "easy to use" might be an overstatement. I spent a fair bit of time trying to get in to the flex/bison workflow and it never seemed to click. I've found it much easier to use PEG parsers, parser combinators, or a hand-written recursive descent parser. Based on their ubiquity and the high reviews, I'm sure they're great tools once the initial hump is passed but that initial hump is quite large.

I recently played through Doom and Doom II via GZDoom and had a great experience playing at 1080p and with disabled texture filtering. I didn't play these games when they first came out so mouselook feels natural to me and I'd recommend it for people in similar positions. These games really do hold up

being proud of one's economic transaction history would be awesome.

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.

Seems like the link ought to point here: https://impervious.com/beacon

I've been a web dev for about 10 years. My day to day now involves building out React-based applications dealing with both the backend and frontend. I put in the work and built a real side project using Tailwind and it was so annoying.

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.

Found the toxic person. RTFM isn't really the best look and I love answering noob questions even if I've seen them a number of times.

So incredibly true. I used to be staunchly in the "estimates are empty promises made by business people" camp. The last couple of years I've worked in an environment where both engineering and product understand that estimates are not created out of thin air and they have real consequences on both sides of the coin.

Our estimates have become far more accurate not only because we all understand that they _are_ estimates but because engineering is able to creatively come up with solutions that meet the business needs, not just the outlined "requirements." Most importantly, any potential shifts in our estimates are communicated every week and we have built in float time to account for these shifts. We haven't missed an estimated date in over a year.

They're talking about the @apply directive. It takes a list of classes and creates a single class with those properties. Since Tailwind classes generally map almost 1-to-1 for CSS rules, it'd be easier in my opinion to just write the CSS directly.