[strogonoff]

For the first part: yes, but that is why I think it is important to stress dependency vetting.

For the second part, a couple of times when I had to add a bit of purely client-side reactivity to something pre-existing but did not want to introduce any build step I simply aliased createElement() to el(). That said, personally I prefer TypeScript for a project of any size, so build step is implied and I can simply not think about converting JSX. Webpack triggers bad memories but esbuild is reasonable.

[emseetech]

FYI I use jsdoc for typing in my IDE so I get the benefit of types without the build step.

[strogonoff]

I like when it simply does not compile, which also helps if there are other various team members (or future me) who can not always be trusted to ignore typing errors. Also, I may be wrong, but I feel like JSDoc types are a bit limiting (and more verbose & extra effort) compared to inline TypeScript. Coming from Python, I really enjoy the typing power of TS and do not want to compromise on that…

[emseetech]

I prefer to just run tsc to check for type errors on GitHub commits instead of needing them for every change.

And yeah inline types are more verbose but I prefer to use .d.ts files for definitions and then declare with a comment (vim lets me move to definitions with ctrl-] which is nice).

I also come from a Go background so I actively don't like using the more esoteric and complex types that typescript provides.