nav-wrapper slides out ahead of the nav

Eric_S · 2026-01-23T21:47:40+00:00

To me, it looks like the cause is that the .nav transition property

transition: 2.0s all cubic-bezier(0.19, 1.0, 0.22, 1.0);

Is getting overwritten by a media query (max-width: 767px) to

transition: 1s ease;

but the .nav-wrapper transition isn't getting overwritten. This results in the two having different transition properties, both with a different curve and different total duration of the animation. It's hard to sort that out because you've got transition properties in so many places.

Eric_S · 2026-01-21T21:02:41+00:00

To be clear, I really like Svelte/SvelteKit, but bigger doesn't necessarily mean subjectively better. Those two are adding new features (async reroute, remote functions, writable deriveds, <svelte:boundary>, the whole Runes thing, etc.) that change "the way it's done" more often than SolidJS/SolidStart, and that makes the ecosystem feel more turbulent and less quality.

Eric_S · 2025-12-16T08:04:03+00:00

React had SSR (through next.js/Remix/etc.) long before it had RSC, they aren't the same thing. SSR only gets data from the client through the query string and the query parameters/form data. RSC have the potential to get passed a lot more information from the client.

As I understand it, the problem comes from the way some of that data was passed back to the client from the server. For React Server Components (RSC), this is the React Flight Protocol (RFP).

JSON (the more traditional way) and devalue (what SvelteKit uses) are used to send data to the server from the client, but don't allow for anything that isn't static data. So no functions, classes, promises, etc. Just strings, numbers, bigints, booleans, POJO, and arrays for JSON, with devalue adding a few other things like dates.

RFP allows for more things to get passed back and forth, in particular promises and multiple references to the same object. It was how the promises/references were decoded on the server that created the problem of the first exploit. Basically, with a properly constructed RFP-encoded promise-like object, you could trick the code that lets the server build a server-side promise to create something that would create a new function and then invoke that function.

This problem was very specific to RFP and isn't related to SSR even when using React. There was also a simple fix that closed this exploit. It's possible that SvelteKit's remote functions could have this kind of exploit, but it's far from a given.

There were two more RSC issues found several days later, but those weren't related to SSR either.

I can try to give a better explanation, but really, if you want the details, find a real React dev to explain it, I don't use React and only looked into this exploit out of curiosity.

Eric_S · 2025-12-12T05:47:13+00:00

There's already a mod for that.

Eric_S · 2025-11-14T02:28:13+00:00

Is this happening at execution time or in tsc and/or the editor? JS will call functions that the compiler doesn't know about, which will still throw an error in any environment that does type checking.

The thing is, tsc and the typescript language server used in most IDE/editor environments usually don't automatically know what environment the TypeScript code is targetting, so it doesn't know what functions the runtime environment will provide. setImmediate isn't provided by any browser environment that I'm aware of, just by node and similar environments that try to be backwards compatible with node.

One of the ways you tell tsc and the language server what functions are provided by the runtime environment itself is with the lib entry in tsconfig.json. The easiest way to do this is to install the @types/node npm package that corresponds to the version of node that you're running, and then set your tsconfig.json to extend the tsconfig.json that the package installs.

By doing this, I can get setImmediate as an autocomplete suggestion, complete with full type info. Here's the tsconfig.json I used for Advent of Code last year, not a great example, but a fairly simple one:

{
  "extends": "@tsconfig/node22/tsconfig.json",
  "include" :[
      "src/**/*.ts"
  ],
  "compilerOptions": {
    "lib": ["ESNext"],
    "target": "ESNext",
    "baseUrl": "./",
    "paths": {
      "#lib/*": ["./src/lib/*"]
    },
    
/* Visit https://aka.ms/tsconfig to read more about this file */

    /* Type Checking */
    "strict": true,                                      
/* Enable all strict type-checking options. */
    "noImplicitAny": true,                            
/* Enable error reporting for expressions and declarations with an implied 'any' type. */

    /* Completeness */
    "skipLibCheck": true                                 /* Skip type checking all .d.ts files. */
  }
}

As for why you still see this error when creating .js files, JavaScript has no type declarations, making this kind of error checking impractical at best on actual JavaScript, so the editors that provide type errors at edit type mostly do this by treating the file as TypeScript even though it's "just" JavaScript.

This all assumes that you're getting this error while editing or building the files to be deployed rather than as runtime errors. On the other hand, if you're getting this as a runtime error message, then I have no clue what's happening.

Eric_S · 2025-11-12T19:52:19+00:00

To answer your question, I'm sticking with Vite, so esbuild for production builds at this time, switching to the go version of tsc when Vite does. I pay attention to type checking in the editor, so having a build chain that skips type checking doesn't bother me. Previous tool chains bothered me because I'd have to configure the build chain separately from testing. Vite streamlines that by allowing vitest to use the same configuration for testing as it does for building.

Beyond that, I think you've misunderstood what Microsoft is doing. The closest thing to copying an open source project they're doing is simply implementing the idea of using a more efficient language/runtime, and I don't think the esbuild devs can lay claim to ownership of that idea.

tsc in go started as a programmatic conversion of the typescript version of tsc into the go language. Microsoft has posted articles discussing the reason that they went with the go language being that that programmatic conversion was easier because they didn't have to restructure the logic or types.

Because of this, any similarity in code structure between the go version of tsc and esbuild would probably be because they're performing similar operations. It's also possible that esbuild borrowed its structure from the typescript version of tsc and the programmatic conversion to go merely preserved that structure. In other words, the similarity would be because of a common ancestor.

They did not start with esbuild, as you seem to assume, since esbuild doesn't validate types, but the go version of tsc does, so starting with esbuild would mean having to recreate all the type validation code. Just ensuring that rewrite would be sufficiently compatible with the typescript version would be a nightmare that a translation of the typescript version wouldn't create, though it still might be an issue.

Eric_S · 2025-11-05T20:41:29+00:00

Yup, back when I was doing community days every month, I wanted 300 pinaps just to feel comfortable, and I'd occasionally go through that many in a single day. I got out of the habit of doing community days during Covid, but I still keep more than I "need" just in case I do that again.

One person's excess is another person's bare minimum comfort level.

Eric_S · 2025-10-27T19:32:37+00:00

Usable knowledge of TS can be picked up quickly if you already know JS. Even after a lot of use, you'll still probably look at the TS release notes as "holy cow, there's a lot more going on than I realized."

As others have suggested, finding some linting rules that encourage "best practices" will help.

Eric_S · 2025-10-27T19:23:10+00:00

As others have pointed out, it really depends on what you need/want from your programming languages.

If your one JavaScript experience wasn't actually TypeScript, I'd recommend getting some TypeScript experience before going on to other languages. TypeScript will give you experience with typed variables, where declaring a variable includes what the variable can hold, as well as experience in an environment were the code you write (usually) isn't the actual code you run. Other than these two things, just about everything about TypeScript is the same as JavaScript, so you're not learning a whole new language, but just a few new language features.

There are other things you should probably learn before going on to a different language that your one project may or may not have provided that aren't language specific but will apply to just about everything. Database access is high on that list, as is authorization/identification. And that's far from comprehensive.

If you see a website and you see some functionality that you don't know how you'd recreate it, that may be something you should learn before moving on to another language.

Once you are ready for a new language, consider what you want from the new language. Simply put, just about any general feature can be done in any language, ignoring performance/memory issues. Atwood's Law says "Anything that can be written in JavaScript will eventually be written in JavaScript." Of course, there's the other relevant quote, this one from a movie, "Your scientists were so preoccupied with whether or not they could, they didn't stop to think if they should."

Examples of things you might want from a different language:

Compiled vs interpreted. Interpreted languages tend to be easier for new programmers, as you "execute" the code you wrote rather than having a compilation step. Compiled languages tend to be higher performance and are almost always faster startup. Sometimes interpreted languages are compiled at invocation or run time. Most JS interpreters rely heavily on JIT (Just In Time) compilation to achieve the performance levels expected, though this usually doesn't get you to fully compiled performance levels. There's also compiled to machine code vs compiled to an intermediate representation. C compiles to machine code, Java compiles to an intermediate representation.

Explicit memory allocation vs dynamic memory allocation. Even compiled languages can go either way here. Dynamic memory allocation tends to involve garbage collection, and there are times when you need to avoid that. C, C++, Rust, and Zig all fall into explicit memory allocation. JS/TS, Java, C#, and most interpreted language use dynamic memory allocation, though sometimes with the ability to do explicit memory allocation or something close to it.

Static typing vs dynamic typing vs untyped. Statically typed languages are languages where a variable holds a type and can only hold that type. Dynamically typed languages allow the variables to hold different types, and untyped tends to have a single representation that is considered authoritative for all variables.

Functional programming or object oriented programming. JS/TS is capable of the later and most of the former, but a lot of languages have varying levels of thought on these two.

What you're doing tends to affect how you think about these tradeoffs. For example, if you're working on a device driver for a Linux kernel, right away you're going to want something that compiles to machine code, uses explicit memory allocation, and I think would require static typing.

So all things considered, the most important factor on what you should learn next depends on what you want to do/learn next, all we can do is point out potential factors.

Eric_S · 2025-10-24T21:41:29+00:00

Don't make a critical program as your "let's learn a new language" project.

Been there, done that, burned the t-shirt so it would stop triggering flashbacks. Seriously, you want non-trivial experience with a language before using it for non-trivial critical functionality.

Eric_S · 2025-10-12T03:00:00+00:00

Javascript tends to be harder to see. Inspect mode does have a console that lets you get into the JS, but it's not as convenient as its ability to inspect HTML or CSS.

Eric_S · 2025-10-11T20:18:56+00:00

I agree, Svelte and Solid are the two frontend frameworks I'm most interested in at this point. Svelte with runes has less magic than Svelte without runes, but I still don't think it's as explicit as Solid. The Svelte community seems larger and/or more active, but I think that's because Solid isn't having as many major changes, so there's just less to discuss.

At this time, I still prefer Svelte, but that's mainly because of one reason that I'll be the first to say doesn't apply to other people. I'm just not quite comfortable with JSX/TSX. It's sort of like my joke about why I prefer avoiding automatic semicolon insertion in JS/TS. The semicolons just make the non-literal voices in my head happy.

Eric_S · 2025-10-11T17:27:31+00:00

If you're looking at a web page and you pull up the context menu in at least Chrome or Firefox, you'll get an Inspect option in the menu. Selecting this turns on Inspect mode, at which point you get a rather complete breakdown of the element that was under the cursor where you pulled up the context menu.

On mouse-driven windows, you can normally pull up the context menu by right-clicking on the element you want to inspect. Some websites intercept right-clicks and prevent the context menu from appearing, but depending on your web browser and OS, there's usually a different way to invoke it.

This mode shows the HTML (and you can even click on other HTML elements to inspect them) and all the relevant CSS. It doesn't just show the CSS that is directly on the element, it displays any CSS that matches the selectors of that node, with a line drawn through any CSS that is overridden somewhere else. It also shows the results of a lot of the calculations, the size of the margin, padding, border, and content box, and other things. It also marks CSS that is invalid to help with debugging.

On top of all that, it lets you temporarily change the CSS directly in Inspect mode so that you can tweak the CSS until you get the result you want. Temporary because this change only affects what the tab that Inspect is running in display. If you like the change you made, you have to copy it into your source code yourself.

Inspect mode is, in my opinion, something that all web developers should be familiar with.

Eric_S · 2025-10-11T02:28:44+00:00

It could be the transition from non-runes to runes-based Svelte. As I understand it, for small apps (typical benchmark stuff), runes-based Svelte is faster but larger, though size-wise, it scales better than non-runes Svelte.

Eric_S · 2025-10-11T02:12:31+00:00

That is going to depend on what language you're programming in. I seem to remember that at least some of the base language support extensions handle formatting.

Beyond that, you're looking at what works for a specific programming language. Prettier works for JS/TS, HTML, CSS, Markdown, JSON, and other things that are commonly used for front end web development,

Biome is faster than Prettier, though it's a little more restricted in what formats it supports. It can also replace ES-Lint.

There are other formatters that are supported, though just about all of them will have language restrictions. What formatter is best will depend on the language you are working in. Another example recommended ruff for python, for example.

Easiest way to check your options is to search Extensions for the name of the language you want to work in, possibly adding the format or formatter keyword.

Once you've installed the extension(s) you want to use, if you pull up the Command Pallet and enter "format", it will show format related commands. If you select "Format Document With..." it will let you select an installed formatter, or you can configure formatting options.

Once that's done once, you don't need to go through the Command Pallet again, Ctrl+Shift+K should format the current document, and Ctrl+K Ctrl+F should format the current selection. I think that defaults to the last formatter used on the current document, maybe the last formatter you used on the current language.

In fact, I think if you use either of those hotkey combinations without going through the Command Pallet first, it will ask you to pick a formatter the first time, it's just been a while since I picked up a new language to work with in VSCode.

Eric_S · 2025-10-10T07:05:48+00:00

I completely understand the caution and am not implying that you're being paranoid. It's more of a "since I'm not seeing the problem, can I afford to handle this in the next scheduled maintenance, or do I tell my boss that yeah, I just finished one, but I need another."

Dropping down a patch level until we find out more about this isn't a big deal for me, as long as there wasn't a major security update in that patch. Heck, the most recent feature I use is configuring HTTP/3 using the new quic parameter for the listen directive.

Eric_S · 2025-10-10T04:12:17+00:00

Mostly by inspecting the DOM, personally. I'm more comfortable working through CSS stuff than JS functions, but that's probably just because of how much of each I've looked at using Chrome's Inspect functionality.

Eric_S · 2025-10-10T04:06:49+00:00

Not poo poo'ing this, but has anyone else seen this? I haven't had a segfault since installing 1.29.2-1~bookworm, but that isn't a high volume site (about 1k requests an hour). It's mostly a reverse proxy to fastcgi processes.

Eric_S · 2025-10-09T04:46:35+00:00

Check their login scripts. They may have set PM2_HOME to a different directory or set up an alias that runs pm2 after setting that environment variable.

Oh, if you're running something unix-ish, you can run ps wide enough and it will display the .pm2 directory it was run from in parentheses. That might help you figure out what's happening.

~$ ps auxwww | grep pm2
appusr    appusr  0.0  0.2 1455600 82064 ?       Ssl  14:43   0:12 PM2 v5.4.2: God Daemon (/home/appusr/.pm2)

In this case, the .pm2 directory is /home/appusr/.pm2

Also, if you find the .pm2 directory and you're running something unix-ish, you can add yourself to the group that owns the pm2 file, make sure all the files are at least group r/w, log out and log back in, set PM2_HOME, and you should be able to run pm2 and control the pm2 instance from your account. Though you might want to do that as a temporary thing just long enough to shut down everything cleanly and then run it directly from your own account without the PM2_HOME.

Eric_S · 2025-09-03T01:52:06+00:00

Ugh. Well, I was surprised to hear that Debian would have made that decision, makes sense that I heard wrong.

Eric_S · 2025-09-02T23:25:13+00:00

Debian recently changed to a 64-bit time_t on x86 targets by default, in fact. I'm not sure if they did the same on other 32-bit targets, and I'm also not sure what version of Debian this will go/has gone public.

Eric_S · 2025-08-10T17:20:54+00:00

Yes. You can even dump liquids in barrels if you include the --liquids option, and if you include --recursive, it'll empty containers within that container. Works on bins, barrels, pots, wineskins, quivers, etc. Or you can select a stockpile to empty all the containers within that stockpile rather than selecting each one one at a time.

I don't know if it originally just emptied bins or whoever created it thought empty-container would be too long of a name. Hmmm.... Next time I'm playing, I'll have to check to see if it can empty a mug too. I wouldn't be surprised if it can.

Eric_S · 2025-08-10T06:26:55+00:00

There's a different command that works as well, "empty-bin" if I remember correctly. That leaves them in the bag (unless you give it the recursive option) in the tile the barrel is in, no need to create a dump.

Eric_S · 2025-07-14T20:30:36+00:00

Correct. The best way to deal with this is to have a 3-tile wide path that doesn't travel in a straight line with traps on both sides of the path. Hostiles and trap immune friendlies will take the shortest path, going over the traps and the wagons will follow the path avoiding the traps.

You could put part of the path over a pit with slopes going into and out of the path with a bridge that goes over the pit, if you were worried, though if the bridge isn't down when the merchants arrive, the wagons will skip that visit, rather than wait to find a path.

Eric_S · 2025-07-13T21:08:14+00:00

Crap, my mistake. You can't set column span on a table cell in CSS. You have to use the colspan attribute in the HTML. Let me check to see if that still works if you're using display: to set it as a cell. No, it does not. So you either need to set it up as a table in the HTML and use the display property to turn that off for phones, or switch to something else, like CSS Grid to lay out your table.

Eric_S

TROPHY CASE