MartijnHols

Rate limits don’t work if bots rotate IPs from residential blocks on every request.

What are you looking for? I use Bunny CDN along with Bunny Shield, and together they're better than Cloudflare for me. It's $10/month, but I can afford it for the privacy of my users. Bunny's aggressive bot blocking without bothering the vast majority of users with regular challenge pages provides a much better UX.

I opted for Bunny Shield exactly to combat bots, in particular ones that spoof User Agents and rotate millions of IPs. It works great, detecting the vast majority of bots and challenging them. Much more user friendly than Cloudflare too, which typically resorts to challenging everyone (not that CF was ever an option due to various concerns).

I also added various rate limits such as 1 RPS to my expensive SSR pages, after which a visitor gets challenged. Again this blocks bots without harming power users much.

Telling a new contributor no thank you is hard. Open source contributors are hard to come by, and so I’ve always dealt with PRs like this (albeit before AI days but from people who had never written a line of code before their PR) by leaving a message that it’s a huge PR so it’s going to take a while to review it and a request to make smaller PRs in the future. A couple of times I ended up leaving over a hundred review comments, but most times they were all fixed and the contributor stuck around with many better PRs later.

One thing to consider is that if you were to succeed in placing hidden text/image on an ID card, it may fail manual forgery checks at airports and police stations. One of the many ways IDs are checked is with different types of lighting[1]. This might have made this stand out as an artifact, which could result in an officer doubting its legitimacy.

[1] https://www.airport-suppliers.com/supplier-press-release/the...

Depends on the project. For websites I like to use a statically generated Nextjs site served by nginx[1] and for SPAs Nginx that serves a Vite-built static bundle with a backend that’s in whatever language the backend team chose.

[1] https://martijnhols.nl/blog/how-much-traffic-can-a-pre-rende...

A 15+ second load on a gigabit connection is impossible to have anything to do with the React library, as React is only kilobytes big and has no impact on the host.

Fair enough. The quoted statement doesn't hold outside the context of the argument that Preact has feature parity. You can build the same apps with Preact and those others, you just need to sacrifice other things.

I think the same generic answer _does_ apply to most mature projects. Libraries like these should be approached like discussions about starting over in mature software projects; "this time we'll do it correctly", or "this framework is much simpler". This applies very much to libraries such as these.

When the complexity is low, projects are easy to learn, maintain and handle. That really makes them seem better and have advantages – advantages like a much reduced bundle size. But these new setups just don't do the same thing. It's a shell of what the old project did, as it's missing solutions for hundreds of edge-cases and other requirements that were tackled by the mature many-year old project that is maintained by some of the best developers. I'm sure React has a bit of bloat, but I'm willing to trust the React team that the vast majority of it is there for a reason. It might also be the cost of building on top of a very mature solution.

Would you not shut such a discussion down when someone new in the team proposes a complete rewrite?

Preact does not have 1:1 feature parity, if it had it would have been much more widely used (who wouldn't want a free filesize reduction?). Preact has plenty of issues, which is why it isn't as widely used.

If Preact truly was as feature complete as React, it would be used by everyone by now – it's old enough for most teams to be aware of it. The fact that it isn't widely used is case in point.

Why would React be bigger and slower than it needs to be? It's a very mature project with a professional development team behind it, I'm sure we can trust them to tackle whatever unnecessary bloat they may have. I think we should be able to trust that anything that is in there serves a purpose, and that it serves hundreds of niche edge-cases that someone will eventually run into but are non-obvious until it's widely used.

These kinds of statements are only true if you're willing to sacrifice in other areas such as maintainability, security, stability, compatibility, accessibility, extensibility or something similar.

There is no such things as a true apples to apples comparison for libraries such as this. They all cherry pick something and ignore a ton of things such as:

  - accessibility
  - amount of libraries with plug-and-play solutions to common problems
  - security
  - scalability
  - rendering performance
  - maintainability
  - browser support
  - browser extension interference
  - hundreds of other niche edge-cases that someone will eventually run into but are non-obvious until it's widely used

The article mentions they inject a web component. I imagine a bad actor could add something to that. In this case at the very least the author could add a "I hacked your Grammarly extension" text just via CSS, but I'm sure you can go much further, even more so with other extensions (eg password managers).

While Google Translate's interference sucks, with current browser tools, I don't think they can really operate any other way.

This is mostly because of cases where they need to translate a sentence like "[Click here] for more information". When translating it to another language, they may have to move the link to the end e.g. "For more information, [click here]". The only way to achieve that is to shuffle DOM elements around, which can cause interference with interactive apps.

There's still a lot the Google Translate team can do to reduce the interference they cause, but I don't think they can fully eliminate it without some new browser APIs.

Unfortunately browsers don't really provide good solutions for extensions that need to inject or change sites. Look at Google's owner in-browser translate extension, its DOM manipulation breaks many interactive apps as well. There are no tools available in browsers for it to not need to do that.

It's not just noise though; clients are actually experiencing crashes and other issues because of it. I wrote an in-depth article on the Google Translate extension's interference of React (and other webapps): https://martijnhols.nl/blog/everything-about-google-translat...

It's no wonder frontend has a lot more errors, after all it has to support so many more client variations than a typical backend. It can be very hard to make a big webapp that works well for everyone.

Makes me wonder if you can use this to hijack their plugin. At the very least you should be able to inject text into it, but you can probably render a pretty little login form as well, abusing the trust the user has in their extension. Is injecting elements into a document controlled by others really safe?

At no point would I say web development is super simple. It's hard to get started, it's hard when something gets larger/more used, and it's hard when things are massive.

There are so many things to consider, as the original post shows. On top of that is:

  - accessibility
    - screen reader support
    - testing
  - usability
    - animations/transitions can help and are another can of worms
  - SEO
  - consistent user elements -> interface components
  - responsiveness
  - performance
    - minification
    - lazy loading images
    - optimizing images (eg serving a 200 kB webp/avif instead of a 5MB JPG)
  - caching/scaling so your server doesn't go down when Hacker News/Reddit links to it
  - hosting cost
  - security
    - CORS
    - CSP
  - forms
    - validation
    - feedback
    - helping users fill it in correctly with as little friction as possible
  - user content sanitization
  - rate limiting
  - licensing
    - of the content you make
    - images you use
    - libraries you use

This wasn't my experience. Hacker News felt surprisingly welcoming as soon as I upped the depth and reduced the opinion.

There are some areas I noticed Hacker News isn't very interested in, such as web accessibility (other platforms picked that up much better), but I think that has more to do with the not-as-exciting subject than the writer/blog.

So long as your article has a decent enough structure – which this article makes it seem is the only thing that matters – I reckon there are two ways to make blog posts that developers read and share;

1. make so many of them, you'll repeatedly hit gold eventually

2. go the extra yard with research and/or effort

The intro's "The developer had interesting insights" makes it sound like they failed blog was full of opinion pieces. Very few opinion pieces succeed, but they're the easiest to write (i.e. the first category). It might work for some people, but for us unknowns, nobody really cares. Go the extra yard and make it interesting by doing a deep dive of the subject.

I've fully focussed on the second approach. As a consequence, each article takes a lot of time to complete, so I generally don't finish more than one per month. I try to make them all something I can actually be proud of (which is quite a challenge), and then I spend a lot of time tweaking the structure, making things less verbose, and improving scanability – I rely on making sentences bold a lot for that. I try to use relevant images, but I find actually helpful ones are hard to make for developer content. While hiring illustrators is a good idea, I doubt many writers are willing to pay for that.

To make my articles more interesting, I try to make a custom component for each article to spice it up and slowly grow the component library I have available for my blog. It doesn't always work though – for my last article I spent several hours building an easter egg that only 22 people (<0.1%) interacted with it.

Even on European servers, it’s still controlled by a US organisation, so if Bitwarden is required to shut down access, they will. For an example where this happens, this court verdict from The Netherlands shows Microsoft's Dutch branch refusing to grant access to data (on its EU servers) of a Dutch company, to a Dutch curator who by law must be given access, because of trade sanctions on the majority owner: https://uitspraken.rechtspraak.nl/details?id=ECLI:NL:RBAMS:2...

I expected it to be much harder to move away from these services I heavily relied on like Microsoft 365. Before I started migrating it figured I was so entangled in their web, that switching to an alternative would be a tremendous task. After actually migrating these services, I managed to migrate 90% within a few hours per service. This is nowhere near the amount of effort I expected it needed. Because of that, I'm also optimistic about migrating Git and NPM. While I don't think NPM will be any different, I suppose my optimism about Git might be misguided because of the amount of customization that goes into setting up CI/CD. Still, since only one out of all of the services might be hard - one that doesn't handle any PII - I stand by saying the overall effort was easier than expected.

Oh, impressive how browser extensions can live outside of browsers now. And on mobile too!

After having used Bitwarden for more than 4 years, I only switched last week, so I'm still in the honeymoon phase. But it has everything I used in Bitwarden and more, most notably all the usability features that I was missing in Bitwarden.

Don't think you can self-host it, but that would also pretty much defeat the user-friendly aspect. You don't need the server source if the vault is client-side encrypted, besides you would get zero guarantees that what they show and what they're actually running are the same thing.

Proton Pass truly doesn’t get enough credit for being completely open source, more user friendly, and hosted outside the US (wouldn’t want to lose access to your vault [1]).

[1] https://berthub.eu/articles/posts/you-can-no-longer-base-you...

My mistake, I missed that the data was limited to "personal" information.

By that definition, wouldn’t sharing total monthly users for the basic purpose of landing some kind of deal (could be as simple as a partnership), constitute “selling data”? Stats like X million monthly users doesn’t appear to conflict with the spirit of the claim, but does conflict with that legal wording.

I reckon it really depends on the kind of clients you’re looking for. I’ve had clients call that just started building an app and were looking to hire their first dev. They didn’t need a resume, but also found me too expensive.

Most companies that are interested are aware of the going rates. But they want to be sure I’m as good as my marketing says - many companies have been burned before by seniors who weren’t senior - so in my experience they usually do ask for a resume and an interview just like an employee. Main difference seems to be the trust in the work I’ve done; I’ve never been asked to make an assessment. That might also be because I filter out these clients before we get to that point.

Anything that affects the DOM and relies on TextNodes behaving predictably. It could be as simple as `e.target` of a click event being different (the `font` element gets in between what was actually clicked), but the main issues are when apps try to update or replace what used to be TextNodes.

Imagine you're building a framework, and a consumer renders a clock. The only thing that changes every tick, is the text value; `00:00` becomes `00:01`. In an attempt to be as efficient as possible, it's only natural for the framework builder to decide to keep a reference to the `TextNode` and only update its `textContent` every frame. This scales the best for even the most complicated app, but it leads to interference from Google Translate as the article shows.

They both do reasonable things, so I wouldn't really blame either. Google Translate was there first and is a big accessibility advantage for the web. At the same time, Google Translate is the user-specific browser extension that is executed last, on top of existing apps. It affects not just React[1], so even if React were to implement a fix, Google Translate would continue to interfere with other webapps.

I think any real fix to Google Translate would be very complicated. I fear the only solution might be to elevate Google Translate to be part of the browser's rendering engine instead of acting like an extension. This would allow it to work in the rendering pipeline without modifying the DOM, but even that will probably run into site-bugs because of things like text being longer or shorter.

[1] https://martijnhols.nl/blog/everything-about-google-translat...