ksbrooksjr

Location: United States (Eastern Standard Time)

Remote: Yes (exclusively)

Willing to relocate: No

Technologies: TypeScript, JavaScript, HTML, CSS, Node.js, React, Preact, Deno, Bun, Cloudflare Workers, Debian, Docker, and Ansible.

Résumé/CV: Available upon request

Email: hn@ksbrooksjr.com

I'm a full stack web developer who's been developing web applications for 8 years. I currently maintain a Chrome Extension that I released in 2017 with over 6,000 users that was Product Hunt's Product of the Day in September of 2017.

Location: United States (Eastern Standard Time)

Remote: Yes (exclusively)

Willing to relocate: No

Technologies: TypeScript, JavaScript, HTML, CSS, Node.js, React, Preact, Deno, Bun, Cloudflare Workers, Debian, Docker, and Ansible.

Résumé/CV: Available upon request

Email: hn@ksbrooksjr.com

I'm a full stack web developer who's been developing web applications for 7 years. I currently maintain a Chrome Extension that I released in 2017 with over 6,000 users that was Product Hunt's Product of the Day in September of 2017.

SEEKING WORK | United States | Remote

I'm a full stack web developer who's been developing web applications for 7 years. I currently maintain a Chrome Extension that I released in 2017 with over 6,000 users that was Product Hunt's Product of the Day in September of 2017.

I have extensive experience working with TypeScript, JavaScript, HTML, CSS, Node.js, React, Preact, Deno, Bun, and Cloudflare Workers. I'm also well versed in traditional Linux system administration, devops, Debian, Docker, and Ansible.

Website: https://ksbrooksjr.com/

Email: hn@ksbrooksjr.com

I wrote a whole blog post about this (unfortunately HN immediately marks my submissions as dead), but I've been developing a minimal little template that uses:

- hono for routing on the server

- preact for building the ui

- goober for styling

- wouter-preact for client-side routing

The whole thing has 6 prod dependencies, 3 dev dependencies, and 17 dependencies total if you include transitive dev and prod dependencies. It can be deployed to any JS runtime (including edge runtimes like Deno Depoy and Cloudflare Workers).

SEEKING WORK | United States | Remote

I'm a full stack web developer who's been developing web applications for 7 years. I currently maintain a Chrome Extension that I released in 2017 with over 6,000 users that was Product Hunt's Product of the Day in September of 2017.

I have extensive experience working with TypeScript, JavaScript, HTML, CSS, Node.js, React, Preact, Deno, Bun, and Cloudflare Workers. I'm also well versed in traditional Linux system administration, devops, Debian, Docker, and Ansible.

Website: https://ksbrooksjr.com/

Email: hn@ksbrooksjr.com

Location: United States (Eastern Standard Time) Remote: Yes (exclusively)

Willing to relocate: No

Technologies: TypeScript, JavaScript, HTML, CSS, Node.js, React, Preact, Deno, Bun, Cloudflare Workers, Debian, Docker, and Ansible.

Résumé/CV: Available upon request

Email: hn@ksbrooksjr.com

I'm a full stack web developer who's been developing web applications for 7 years. I currently maintain a Chrome Extension that I released in 2017 with over 6,000 users that was Product Hunt's Product of the Day in September of 2017.

No one is seething. HN is filled with these low quality "js developer bad" comments these days. I have no idea what a "meme developer" is.

Location: United States (Eastern Standard Time)

Remote: Yes (exclusively)

Willing to relocate: No

Technologies: TypeScript, JavaScript, HTML, CSS, Node.js, React, Preact, Deno, Bun, Cloudflare Workers, Debian, Docker, and Ansible.

Résumé/CV: Available upon request

Email: hn@ksbrooksjr.com

I'm a full stack web developer who's been developing web applications for almost 7 years. I currently maintain a Chrome Extension that I built in 2017 with over 6,000 users.

SEEKING WORK | United States | Remote

I'm a full stack web developer who's been developing web applications for almost 7 years. I currently maintain a Chrome Extension that I built in 2017 with over 6,000 users.

I have extensive experience working with TypeScript, JavaScript, HTML, CSS, Node.js, React, Preact, Deno, Bun, and Cloudflare Workers. I'm also well versed in traditional Linux system administration, devops, Debian, Docker, and Ansible.

Website: https://ksbrooksjr.com/

Email: hn@ksbrooksjr.com

Yeah this code definitely wasn't designed to win any performance contests. I was mostly optimizing for readability. The easier it is to understand code, the easier it is to audit it from a security perspective.

The author of that blog post admits he doesn't fully understand Lemire's algorithm despite attempting a Rust port of it, and his functions only support a max range of 256 numbers (8 bits), whereas Lemire's version topped out at 64 bits, and the simplistic version I've outlined in this post supports 32 bits.

This isn't a criticism of the post's author of course, because Lemire's algorithm is inherently complex.

Erlang is definitely more fault tolerant than most languages, but I've found that static typing tends to catch a lot of errors in development that would otherwise crash an application in production. The compiler won't catch every bug, and you'll still typically have to restart a crashed service periodically (via systemd, or a container orchestrator, or whatever process manager you use), but it definitely helps.

Gleam is a pretty good choice if you need type safety and you want to run on the BEAM https://gleam.run/. It still has the same performance characteristics as Erlang (which it compiles to), but at least it gives you type safety.

I wasn't trying to imply that concurrency is the only way to mitigate ReDos attacks, I was just pointing out that the BEAM applies preemption seemingly everywhere, which I found interesting.

There are definitely trade offs when switching from Elixir or Erlang to Go. If you're a functional programmer who can't live without immutability, or you plan on running a cluster of machines that can communicate with each other and hot-swap code into the running system, then Elixir and Erlang are good choices.

If you have some extremely CPU intensive code, or you like cross compiling to a lightweight binary, or you need static typing (without giving up preemptive scheduling), Go is a decent choice.

Elixir and Erlang are not slow by any metric, but there are faster languages. Discord famously had to augment their Elixir code with Rust for example to scale to 11 million users [1].

[1] https://discord.com/blog/using-rust-to-scale-elixir-for-11-m...

Yeah with preemptive scheduling, static typing, and better cpu utilization Go is a pretty compelling option for Erlang and Elixir users.

I'm not a Go expert but preemptive scheduling of goroutines is supposed to be one of the primary benefits of Go as a language [1]. Although I'm not sure if there's any runtime that adopts preemptive scheduling as fervently as the BEAM. Even the regular expression engine is preemptive in Erlang, which prevents regular expression denial of service attacks [2].

[1] https://go.dev/src/runtime/preempt.go

[2] https://www.erlang.org/doc/man/re.html#:~:text=run/3%20alway....

Javascript random number generators don't let you choose an arbitrary range. So if you have an alphabet of 26 characters (0-25) you would have to generate a random number by running:

  crypto.getRandomValues(new Uint8Array(1))[0] % 32

And then filter out the value if it falls outside of your range (0-25).

It looks like the plaintext is being padded so that its length is a multiple of the block size [1]. I can't find any resources that say you need to pad a message before encrypting it with AES-GCM though. The official examples from MDN [2][3] don't pad the message before encrypting. The source code links to a wikipedia article that states that padding isn't necessary for counter mode, which the code is using (GCM is Galois Counter Mode)[4].

[1] https://github.com/mprimi/portable-secret/blob/6efdb4618216f...

[2] https://developer.mozilla.org/en-US/docs/Web/API/SubtleCrypt...

[3] https://github.com/mdn/dom-examples/blob/main/web-crypto/enc...

[4] https://en.wikipedia.org/wiki/Padding_(cryptography)#PKCS#5_....

I really enjoyed listening to this podcast, and I'm honestly surprised at how low the per episode engagement is. There's no shortage of podcasts focusing on the economic aspect of running a business, or the technical aspect of building the frontend/backend, but there are very few that go into the details of deployment, monitoring, etc. I thought your podcast tapped into a really interesting niche, and I posted a link to it in a previous hn comment [1].

[1] https://news.ycombinator.com/item?id=32987671

Apparently some users have attached smaller wheels to the front of the Onewheel that engage during a nosedive [1]. I wonder how effective these are at preventing injury.

[1] https://old.reddit.com/r/onewheel/comments/903wnj/diy_antino...

Preact would solve most (if not all) of the performance problems listed in the executive summary of the post (build time, time to interactive, memory usage, and maximum data set size). It doesn't seem like a terrible comparison to mention a framework with the exact same api as the one the team in the post was using for 2 years before adopting htmx.

It's a pretty short post, but a lot of it boils down to the fact that the team is using a single language throughout the whole stack (Python), which allows everyone on the team to be a full stack developer. Like I said, if you're against writing js then htmx is probably a better solution for your team.

Well yeah obviously you can bypass the client code and directly connect to a server. That's not my point.

Client side validation doesn't prevent a malicious user from sending invalid requests, but it can prevent legitimate users from sending invalid data to your server accidentally. In fact, if I see validation failures showing up in my server logs for something I know should have been filtered out via client side validation, I can mark that ip address as being potentially malicious and rate-limit their future requests.

And as a user I would rather find out about validation issues immediately instead of waiting for a network round trip to the server. If I'm typing in a password for example and it doesn't meet the website's length/complexity requirements, I'd rather know as I'm typing instead of waiting for an HTTP request to complete. That extra HTTP request is wasting the user's bandwidth and the server's resources.

I read it as a straw man argument, but that might not have been the author's intention at all. It's hard to judge tone through text alone.

If I were using htmx I would still want to validate data on the client and the server. If you don't validate data on the client, then you're effectively allowing clients to DDOS your server with invalid data.

You haven't disagreed with anything I said. My original comment says "Htmx is great for developers who need client side interactivity, but would rather not write any js". I'm sure a team of Python developers is enjoying not writing Javascript. My point is that you don't have to switch to a completely different paradigm to reap the performance benefits that the article lists.

Svelte is another great option with a much smaller footprint than React. If you don't feel like setting up SSR by hand, you can also just use Next.js which works fine with Preact [1].

[1] https://github.com/vercel/next.js/tree/canary/examples/using...

According to the article we're commenting on, the programming model is not the sole reason for switching from React to Htmx. Look at the executive summary's bullet points. Four of them are related to performance (build time, time to interactive, data set size, and memory usage). Performance might not be the reason you personally use Htmx, but it's certainly put forward as an advantage in the article which we're commenting on (which is from the htmx team by the way).

I've often seen this meme repeated in debates that js frameworks require you to duplicate logic between the server and client, but most of the logic isn't being duplicated between the client and server, it's being moved from the server to the client. It's relocation, not duplication. Instead of your rails/django controllers deciding what html to render, that decision happens on the client. In this model your server is mostly just an authorization layer, and an interface between the user and the database. Hasura, Firebase, Firestore, Mongodb Realm, and several other products have been successfully built around this premise. You might not like the thick-client thin-server model, which is completely fine, but it's a somewhat subjective preference. The only objective criteria you might use to decide which approach to use is performance.

Yea htmx definitely has a different programming model than an SPA style framework like React/Preact. I actually like the JSON api programming model where the backend is as simple as possible, and the frontend js/ts code is completely responsible for handling the UI, but I guess it's a matter of personal preference.

The linked article is referring to a team switching from React to htmx though, so for them I'd imagine it would've been a much easier transition if they'd just added a Webpack alias[1] that replaced React with preact/compat, rather than switching to a completely different UI paradigm.

[1] https://preactjs.com/guide/v10/getting-started#aliasing-in-w...

Htmx is great for developers who need client side interactivity, but would rather not write any js. If you don't mind writing a bit of js however, you can't go wrong with Preact. Same api as React, but at a fraction of react-dom's bundle size. It looks like the minified source is even smaller than htmx (which is already very minimal) [1][2]. They've also packaged Preact in such a way that you don't need to add a build step to use it [3].

[1] https://unpkg.com/browse/htmx.org@1.8.2/dist/

[2] https://unpkg.com/browse/preact@10.11.2/dist/

[3] https://preactjs.com/guide/v10/getting-started#no-build-tool...

One feature that's kind of difficult to emulate without Javascript is the ability to play media continuously while navigating with the back and forward buttons. Rich Harris talked about this at the 5 minute mark of his video on whether or not SPAs have ruined the web [1].

Youtube actually uses this capability specifically. If you add a Youtube video to a queue, it switches to a picture in picture mode where you can navigate while the video is still playing.

The only other technical challenge is handling animations between route changes. There's a browser api in progress (the shared element transition API) [2], that will allow animations during navigations without client side routing, but it still requires Javascript. Navigation animations are arguably just purely aesthetic though.

[1] https://youtu.be/860d8usGC0o?t=299

[2] https://developer.chrome.com/blog/shared-element-transitions...

I read it, and I empathize with their stance. I'm actually torn between wanting Typescript to be as compatible with Javascript as possible, and wishing we didn't have to wait for TC39's process to play out before using new features (which I've written about before on hn[1]). Given their design goals though, the Typescript team has done a great job.

[1] https://news.ycombinator.com/item?id=32188944