mhagemeister

7 ms·

31.
by mhagemeister 4y ago
Author here. That's great feedback! After reading your comment and re-reading the section in the article it does indeed sound wrong. Decided to remove that paragraph. Your explanation of the string representation is really good. Thanks
32.
by mhagemeister 4y ago
That's a great tip! I noticed a similar speedup when removing other formatting related plugins when I did the research for this article. Originally, I had planned to look into that too, but the article was already getting pretty long.
33.
by mhagemeister 4y ago
Thanks for the kind words! I felt the same way and I'm hoping to fill that gap with this series. I've always been someone who loved to peek behind the curtain to appreciate how things are done behind the scenes. > I really hope
34.
Speeding up the JavaScript ecosystem part 3 – eslint(marvinh.dev)
70 points by mhagemeister 4y ago|14 comments
35.
by mhagemeister 4y ago
No worries, that's valuable feedback. I should have made it more clear in the article that it's not just theory.
36.
by mhagemeister 4y ago
These are good points! There is definitely more appeal to them than I gave them credit for in the article.
37.
by mhagemeister 4y ago
Thanks, happy you enjoyed the article! The PRs for the previous article were all merged. I originally wanted to do the same for this one, but I'm not sure if I have the time to fix all of them. Updating to a newer version of `resolve`
38.
by mhagemeister 4y ago
Author here. Thanks for the feedback. The reason I wrote this article is because we _can_ do something about it. Through avoiding throwing lots of wasteful error objects and adding a little bit of caching, the time it took to lint the proje
39.
Speeding up the JavaScript ecosystem part 2 – Module Resolution(marvinh.dev)
71 points by mhagemeister 4y ago|15 comments
40.
by mhagemeister 4y ago
Author here. Answered this elsewhere here: It's the `--cpu-prof` argument with node and the resulting profile is loaded into speedscope.
41.
by mhagemeister 4y ago
Author here. Thanks for the kind words!
42.
by mhagemeister 4y ago
Author here. True, optimize code for JS engines is certainly an art form of its own. What usually works for me is to write boring imperative code when performance is a requirement. That seems to be easily optimizable by current engines. Als
43.
by mhagemeister 4y ago
Author here. Whoops, good catch! That's definitely an error on my part. The original code uses `var` there. Thanks for pointing it out.
44.
by mhagemeister 4y ago
Author here. I mainly used node's `--cpu-prof` flag to generate a profile. Tried loading the trace into Chrome DevTools at first, but wasn't able to load the file supposedly because they are too big. So I used https://w
45.
by mhagemeister 4y ago
Author here. Yeah, that was surprising to me too. You always discover something you would have never thought of on your own. It's what makes profiling such an enjoyable task for me!
46.
by mhagemeister 4y ago
No, that's because GitHub uses the same number for both issues and pull requests. We did about 70 pull requests. You can verify that yourself by going on an issue and incrementing/decrementing the number until you hit a PR at whic
47.
by mhagemeister 4y ago
Preact maintainer here. Yes, signals can be used independently of any framework. It runs everywhere JavaScript runs. To use it in node without any framework adapters, import the `@preact/signals-core` package, which just exports the re
48.
by mhagemeister 4y ago
Preact Maintainer here. Agree, it explains much better the motivation behind signals. I wish HN would've linked to that instead of the README of the git repository.
49.
by mhagemeister 5y ago
Preact maintainer here. That's amazing! I didn't know that our little project is used in interviews. Happy to hear that you liked working with the code base!
50.
by mhagemeister 5y ago
There is uvu https://github.com/lukeed/uvu which has runtime performance as the number one goal. Maybe that is something for you.
51.
by mhagemeister 7y ago
I'm on the team behind Preact X. If anyone has any questions: ask away :)
52.
by mhagemeister 7y ago
yup, just add the script tag and you're good to go! It's frequently used along with https://github.com/developit/htm for a jsx-less template syntax. No build tools required :)
53.
by mhagemeister 7y ago
There is also Preact which is a 3kb alternative to React with a similar API. https://github.com/developit/preact/ Disclaimer: I'm one of the maintainers.
54.
by mhagemeister 9y ago
Fetch requests do support cancelation for a while now through `AbortController`. See: https://developers.google.com/web/updates/2017/09/abortable-...
55.
by mhagemeister 10y ago
This is really awesome! Minor nitpick: Please remove scrolljacking from the site. Scrolling on a Touchpad on Mac feels off, because of smoothscroll.js