HN user

Akkuma

311 karma

https://github.com/Akkuma

Full stack engineer 15+ years experience. Been writing JavaScript since the cavemen first invented it.

[ my public key: https://keybase.io/akkuma; my proof: https://keybase.io/akkuma/sigs/TDU7XyijyPekAV13MBpvkXUJAv8PemrDtO6wS2e0NnI ]

Posts0
Comments151
View on HN
No posts found.

Location: SC, USA

Remote: Yes (only)

Willing to relocate: If you make selling my house painless perhaps or pay enough to justify it

Technologies: JavaScript, Node, TypeScript, React, Solid, Bun, AWS, CI/CD

Resume/CV: https://akkuma.github.io/resume

Email: JS for my email atob('Z3JlZ29yeXdheG1hbitobkBnbWFpbC5jb20=')

My personal site: https://akkuma.github.io

17+ years in engineering (staff/principal) with 17+ years in JavaScript, Node since Ryan Dahl was working on it, React before it had a major version. Check resume for full list, which includes using lots of TypeScript, .Net, minor Elm, minor Ruby, minor Python, minor Elixir) with interest and willing to learn other languages like Rust.

Location: SC, USA

Remote: Yes (only)

Willing to relocate: If you make selling my house painless perhaps or pay enough to justify it

Technologies: JavaScript, Node, TypeScript, React, Solid, Bun, AWS, CI/CD

Resume/CV: https://akkuma.github.io/resume

Email: JS for my email atob('Z3JlZ29yeXdheG1hbitobkBnbWFpbC5jb20=')

My personal site: https://akkuma.github.io

17+ years in engineering (staff/principal) with 17+ years in JavaScript, Node since Ryan Dahl was working on it, React before it had a major version. Check resume for full list, which includes using lots of TypeScript, .Net, minor Elm, minor Ruby, minor Python, minor Elixir) with interest and willing to learn other languages like Rust.

This is my first time using it and I've been very pleased with it so far. It keeps it simple, has solid typing & schema building, and reminds me of LINQ. I'm also a thin models kind of person and the fact this is just an object without needing to build ORM classes is even better.

Thanks for the insight, I greatly appreciate it! This definitely is a reasonable idea for many things and I'm looking forward to seeing something similar to the sharding mechanism in the future.

I've only started to think about this and I'm thinking the hardest part will be dealing with cross-cutting concerns (in a non-auto sharded world manually creating multiple database) and trying to find a way to keep each database isolated without extra burden compared to using a hosted Postgres.

As an aside, that lan optimized house was a gaming dream. Hope your new house is as awesome.

Is it a non-goal to be long term usable for larger databases? That would force the usage of something like turso your closest direct comparison as a possible migration strategy or relying on "Smart Placement" (which from my point of view reduces the benefit of global edge) for other serverless non-global dbs.

Location: SC, USA

Remote: Yes (only)

Willing to relocate: If you make selling my house painless perhaps or pay enough to justify it

Technologies: 15+ years in engineering with 15+ years in JavaScript, Node since Ryan Dahl was working on it, React before it had a major version. Check resume for full list (includes using lots of TypeScript, .Net, minor Elm, minor Ruby, minor Python, minor Elixir) with interest and willing to learn other languages like Rust.

Resume/CV: JS for my linkedin atob('aHR0cHM6Ly93d3cubGlua2VkaW4uY29tL2luL2dyZWctY2FuLXRoaW5rLw==')

Email: JS for my email atob('Z3JlZ29yeXdheG1hbitobkBnbWFpbC5jb20=')

I'm currently a Staff Engineer who has and can work the entire stack (architected most of the current frontend I work on, write APIs, can work with databases, have created CI pipelines, etc.), but I've been wanting to become some form of Engineering Manager. I've found mentoring and helping others extremely rewarding and I've been told my passion about technology inspires others. I'd be interested in a purely IC job only at a place that really proves it is worth changing from my current company and job. I'm more interested in either a pure manager position or a "50/50 position (the 50/50 cannot be a paid for one job, doing two jobs 100% & 100%).

Location: SC

Remote: Yes (only)

Willing to relocate: If you make selling my house painless perhaps or pay enough to justify it

Technologies: 13+ years in JavaScript, Node, React, check resume for full list (includes using TypeScript, .Net, Elm, Ruby, Python, Elixir) with strong interest in FP and other languages like Rust

Resume/CV: https://stackoverflow.com/cv/akkuma contains all my technologies I've used

Email: Run this js to decode my email atob('Z3JlZ29yeXdheG1hbitobkBnbWFpbC5jb20=')

If you want a full stack engineer or an expert frontend engineer/UI engineer then I fit that quite well.

I'm not here to agree with the who you responded to, but Google smuggling unblockable ads does 100% harm Brave. If part of Brave's selling point is the built-in ad blocking and in a hypothetical dystopian scenario the web were overrun with unblockable ads from WebBundles Brave would inevitably be harmed to some degree. I say that as someone who runs Brave on my phone primarily. I know I'd probably switch browsers if one of the primary reasons to use it were largely killed off.

People used to look at me like I was crazy when I told them that React is nice, but you can actually write faster code with alternative methodologies. It seems like other engineers are coming around to this and creating these faster alternatives.

React made writing frontends generally better, but often slower and as rich_harris points out that it entails a lot of developer work to build and use optimizations to speed it up.

But that's what languages that compile to JavaScript support already today. The binary JS shouldn't prevent this behaviour if it is just a binary representation of a text version.

Sure, why not? The difference is that WASM is aiming for near native performance of code, while the binary JS would still be limited to JS performance.

The file size limit is 4/4.5MB.

I work at Virtru. The short summary is that we make a client-side encryption extension for the content of your email. There are certainly things we can do to reduce the file size. However, the business value of doing so is limited, particularly in the context of an extension. It is also much more limited when Firefox itself is vastly less popular than Chrome today and we have no issues from Chrome.

We use webpack, so all our dependencies, which may not be optimized for file size for browser usage get pulled in as well.

As I previously stated, so not sure why I'm having to repeat this, that the entire process due to the minification creates a huge barrier for any business that is trying to fix things in a reasonable amount of time. You get thrown into an admin queue, which moves at a snail's pace, EVERY time you upload a new version you have to add instructions again, EVERY time there is a different reviewer with the same question you have to answer them again. Mozilla isn't sitting there actually reviewing your source code in an intelligent way. We were dinged on 2 uses of eval. What is hilarious the uses came from within very well known libraries, jQuery, and Bluebird. If they were really reading the source code, they would have known that we didn't write that, 1 of the uses we never call the function that contained it, and bluebird is using it as a de-optimization strategy to prevent a function optimization that make objects fast.

This isn't true if you use uglify at all. I literally had to go into IRC and try and figure out why a hotfix for our extension was taking so long to get through the process (we had been sitting in it for at least 3 days if not a week IIRC). The response I got in IRC was that I would have to literally come and ask for someone's assistance to bump up the review on my company's extension each time we hotfixed, as we got placed in a special queue that required an admin and not just any volunteer in part due to our use of uglify causing the code to be obfuscated.

The worse part is that uglify is required for us to even get the extension signed, due to Firefox's arbitrary individual file size limit.

Prior to Mozilla getting their act together it literally was over a month of waiting for them to review our extension, so we just bailed altogether as their entire process is terrible for pretty much no real gain. I then tried again once the queue had dropped from ~400 to ~150 and the wait time finally became reasonable.

I mean the process was/is so bad, they literally had an issue on github to just automatically approve extensions based on some criteria due to the huge backlog. I cannot get an unlisted extension released with the same version as a listed extension, so we completely bailed on using Mozilla's hosting at all, since all it does is cause a liability until we can push out fixes the same day without manual intervention.

To top this off, every single time we make a new release, we'd have to explain the extension, how to build it, etc. and provide sources to the code. Our extension is also a regular web extension.

Git dependencies with semver support seems to pretty much leapfrog yarn. One of the few reasons for a private npm package is removed with this feature.

I think this is overestimating how qualified the coders are in the east compared to their western peers. Everyone I've known from Hong Kong decried the education of mainland China. They said the education comes down to repeating book knowledge, so just memorization, and the inability to handle scenarios not covered by that.

I'll be more concerned once leading technologies that are used by the rest of the world come out of China and not from the US.

I'm not a Intel or AMD fanboy by any stretch (only ever built with Intel), but I don't know what benchmarks you've been reading and I've read a lot and you'll have to clarify what you mean by worse performance.

In any multithreaded application the Ryzen 1600(x) are just as good if not better. The 1800x to 1700 are even more multithreaded performance and the 1700 is priced a little cheaper than 7700k and able to be OC to the same performance as the 1800x (the entire Ryzen lineup seems to be capable of the same OC, but also capped pretty heavily). The only place that is showing Intel winning are in single threaded scenarios and in gaming scenarios. The gaming scenarios are interesting as one of the more recent benchmarks I saw (https://www.youtube.com/watch?v=3VvwWTQKCZs) was showing in many cases the worse case FPS is better than the 7600k. Additionally, several games have received engine updates that seem to put Ryzen on par with Intel now.

People should avoid using callbacks as they invert the chain of handling function calls. Rather than getting a result that you can work with, you move the logic into another function. Promises compose much more cleanly than callbacks do resulting in generally easier to follow code.

If you call function x with a callback you either handle it immediately via your callback or you have to use some other paradigm to make it compose with other async code. You get no return value allowing you to write code that looks synchronous and forget about the beauty of async/await you've completed abandoned it with callbacks. If you use Promises you can do as you wish and combine them as you wish as they hold values and you can use them multiple times trivially with other Promises,