Joseph Wynn
wildlyinaccurate.com · Personal blog · on HN since 2012
Joseph Wynn is a web developer writing about Git, bcrypt, React, dependency management, and web performance.
What HN saysCommenters cite his Git guide as a favorite resource and point to his bcrypt work factor post, which has a benchmark table of check times.
15HN people shared it
5linked it in comments
17stories submitted
670story points
7 years agolast shared
2012people per year2026
Most-shared posts
- 1A Hacker’s Guide to Git11 people · 424 points · first shared 2014 · 117 comments on HN
- 2A faster BBC News front page3 people · 238 points · first shared 2017 · 125 comments on HN
- 3Bcrypt choosing a work factor2 people · first shared 2015
- 4Introducing Second: a framework for mostly-static React applications1 people · 2 points · first shared 2017 · discussion on HN
- 5Worst fonts for programming1 people · 2 points · first shared 2013 · discussion on HN
- 6Don't use Git's autocorrect feature1 people · 1 points · first shared 2013 · discussion on HN
- 7Blazing fast WordPress with Nginx and Memcached1 people · 1 points · first shared 2013 · discussion on HN
- 8When did dependency management get so complicated?1 people · 1 points · first shared 2013 · 1 comments on HN
- 9Dishonest comments1 people · 1 points · first shared 2013 · discussion on HN
- 10Setting up your editor1 people · first shared 2012
What HN people wrote when they linked it
wldlyinaccurate · 2019-12-21
I've used React as a server-side templating language on many projects small and large. The main feature that makes React great for rendering HTML is higher-order components. In my experience any project of sufficient complexity starts to get ugly with a "regular" templating language. React encourages composition of small isolated components, which tends to result in code that is easier to understand and maintain.
Admittedly this works best on projects that don't require a massively complex interactive front-end, like news sites[0] and data reporting tools. But at some point you can just choose to start hydrating the interactive components in the browser without changing your back-end setup at all.
[0]: https://wildlyinaccurate.com/introducing-a-faster-bbc-news-front-page/
mrdrozdov · 2015-05-10
My favorite resource is a long but clear blog post. http://wildlyinaccurate.com/a-hackers-guide-to-git/
Alternatively, you could attend Recurse Center and sit through one of Mary's excellent git workshops. :)
tomblomfield · 2015-03-27
Yes, you can set the work factor. It seems like the default is around 10 at the moment.
http://wildlyinaccurate.com/bcrypt-choosing-a-work-factor/
amaks · 2014-10-22
I really like the Hacker's Guide to Git:
https://wildlyinaccurate.com/a-hackers-guide-to-git
biot · 2015-03-27
Yes, depending on the work factor chosen. See http://wildlyinaccurate.com/bcrypt-choosing-a-work-factor/#benchmarks for a table of work factors and associated time to check a single password. The work factor is a trade-off involving burning CPU cycles, load on the servers processing logins, and user experience. If you choose a work factor resulting in each password verification taking half a second, it's essentially computationally infeasible to brute force any decently chosen password.
Someone could go through the list of the top million passwords in a week of CPU time and, because each hash has its own randomly generated salt, the effort spent cracking one user's password yields no insight into anyone else's password; the entire effort needs to be repeated per user. If your password has sufficient entropy (eg: long and randomly generated, not appearing in any password lists) then -- barring some revolutionary mathematical breakthrough -- you don't need to worry about someone discovering your password before the heat death of the universe.