How I built a modern website in 2021
kentcdodds.com
kentcdodds.com
"Hi, I'm Kent C. Dodds. I'm a world renowned speaker, teacher, and trainer ..." - https://kentcdodds.com/info World renowned is an extreme stretch. I have never heard of this guy, so if he is even renowned, it is only in the frontend JS world.
https://kentcdodds.com/discord#reasons-to-join While I personally like Discord, I have become extremely wary of people with something to sell advertising a Discord server. You see the same tactic with the crypto and NFT people, where you create what feels like an informal, fun, collaborative space, but really it is an attempt to create a self-sustaining social scene around a specific brand.
Then onto his LinkedIn (https://www.linkedin.com/in/kentcdodds/). He worked at Paypal for a while, preceded by a bunch of no names, and has some weird Google developer certification. Not really the resume of someone who can charge $600 (!) for a course in some frontend BS that will be out of date in 6 months.
His Github has a ton of activity and to his credit it does look to actually largely be "real" and not just gamifying LOC/# of commit metrics.
This guy may well be a react/frontend expert, or at least competent in the space, but this website is just a grift targeting inexperienced engineers.
Like, look at https://kentcdodds.com/clubs for example. Doesn't this read as patronizing at best and one step away from being a pyramid scheme at worst? All it takes is to add a financial incentive to the "Learning Club Captain" position for this to literally be a pyramid scheme.
Ultimately the courses this dude does are “produced” via EggHead.io and the guy has a well documented open source career.
And hey if his stuff doesn’t provide value to you that’s fine. It’s not hurting anyone and if anything is helping people with their careers.
P.S. I follow him on Twitter and he frequently offers discounts and purchase power parity. So it’s made about as financially accessible as reasonably possible.
Hope that helps.
https://reddit.com/r/reactjs/comments/fcvqnl/stop_using_islo...
Many people picked on the distributed nature of the app, along with auth, but I was personally taken aback at the pushing of a pretty obscure, heavy handed state machine library in ‘modern frontend in 2021’, especially just as we are exiting the Redux era into more ergonomic solutions to state management.
There’s a lot of reasonable feedback here, and it all kind of falls under the theme that this guy is pushing a misguided curriculum. I’m not even a fan of Redux, but modest usage of the useSelector hook is far more sensible than xState (or even better, the myriad of newer alternatives that boil Redux down even more to something even simpler). This an important discussion to me personally because I always wonder how newer developers get these concepts fed to them, and voila, here it is.
It’s not hurting anyone and if anything is helping people with their careers.
Unfortunately, I think a good deal of working professionals on HN can agree that it is hurting our codebases, and the overall Frontend community has achieved consensus for some time now that we’ve been feeding bad guidance to everyone.
All I actually saw on his Twitter, and probably the Discord too (if I were to look), was a fanbase providing support. Objectively, all one can take away from that is that his paying customers like the product. That has no bearing on if the product is actually good, just that some people were either accurately or inaccurately assessing the value of it. HN can certainly be full of haters, but it does have a pretty solid group of shrewd experienced developers that won’t appease and ordain things indiscriminately. In this case, as tough as the feedback was, I think HN got it right.
Going on a tangent here, could you suggest any notable library replacing redux to look at?
But there are many, I’m doing them an injustice by not mentioning them. Recoil is another that came from the Facebook team. A lot of thought went into simplifying state management.
It’s really none of my business, one can spend their time and money however they like. But, they do show up to work and advocate for these types of setups and that leads to bad codebases.
I’m not sure how any of us can solve it since Frontend is the port of entry for vast swaths of career-changers and new grads. Then again, I also see the over-engineering on devops, a group that should be a little more experienced. I don’t know where people get these ideas, so we might all be correct in shaking our fist at the Kent C Dobb types for fundamentally being a bad influence.
Just taking a look at one part of the stack, Xstate, how anyone can advocate for this is, I really just don’t know. This is a simple todo list example from it’s docs:
https://github.com/statelyai/xstate/tree/main/examples/todo-...
Eh, I give up. I really have no words for any of this.
When I build a small tool/webapp in 1-2 weeks, using "simple, dumb" technology (even within the React ecosystem), while some of my colleagues take 1+ month to build similarly complicated webapp, and after few months of usages there are 0 reported bugs in my apps and they are still cleaning edge cases.
Then I'm usually brought in to help on some of these projects, and most of my PRs look deep in the red (removing more lines than adding) while still adding features/fixing bugs. That shows part my experience, but also often the better use of the tools.
While this whole thread has been a whiplashing on the OP, it’s only happening because they seem to not get it and continue propagating stacks and layered complexity of this sort. In fact, they are literally selling it to the most impressionable without paying a dime of the consequences (suffering through the n-th over abstracted codebase).
I’ve lost patience.
However, Kent is only using XState in one non-trivial interactive part of the site – the call recorder: https://github.com/kentcdodds/kentcdodds.com/blob/main/app/c...
Seems to me like a proper use of a state machine (I might be biased, though).
You may be right about the selling tactics but the ad hominems are in comically poor taste.
If it's really low, I can imagine why it was made distributed. Otherwise, I'd see that as a demo and an exercise.
In any case, with a distributed architecture there are many parts that can break. Fewer moving parts means fewer broken pieces.
> If it's really low, I can imagine why it was made distributed.
If an extremely low SLA is the goal, I would not be home-rolling a distributed website technology stack. The more moving pieces you have, the more likely one of them is to fail.
The recipe for a high availability, high reliability website is relatively simple in the age of Cloudflare and other cheap hosted services. Introducing a lot of complexity and home-grown solutions is the last thing you want for high availability unless you have scores of engineers to maintain it and you can't solve it through traditional means.
(For a personal informational site I'd take a static site generator.)
Uploading media files to (or from) developing countries with weaker internet infra often results in timeouts and dropped connections. I tried uploading a 8GB file to Singapore S3 from Florida and my connection often timed out.
I'm trying to imagine how you can deliver a fast website to users around the globe without distributed systems.
If this guy were pragmatic, a Ruby on Rails/django app in heroku would do wonders. If he wants to promote React because that's what he sells, that's a different story.
The problem is the people taking what this guy says as "the modern way to do it" and then you find the messes you find at work.
Sorry for my dumbness, but not sure what a repost invite is. Something good I hope XD.
Thanks.
For anyone who's wondering: a repost invite is a way of getting a post into the second-chance pool (https://news.ycombinator.com/pool, explained at https://news.ycombinator.com/item?id=26998308), so it will get a random placement on HN's front page. If the original submission is older than a few days, we don't re-up it, but rather invite the submitter to repost it. Then it goes automatically into the pool. So yes, it's something good :)
(1): https://azure.microsoft.com/en-us/services/app-service/stati...
A single small server running a typical web framework (anything from django to asp.net to laravel) can easily serve all these pages in milliseconds. Add a CDN in front to cache and serve quickly to users around the world.
That's completely different than taking a simple blogging site and turning it into some distributed monstrosity.
So that's where it's wrong IMO, it replaces simple static site hosting/managers/etc, instead of having a single-click toolchain that takes your commits and CI/CD it properly, you now have to install and maintain that yourself manually.`
The "simple static site hosting" isn't magic, it's usually nothing more than a wrapper around putting your code into a nodejs docker container and deploying it to some lambda/serverless platform with a CDN in front. Your post is exactly what I mean about many frontend devs not understanding backend or infrastructure resulting in convoluted architectures.
80% of companies building on top of kubernetes should just pay some provider to do it for them, or use higher level tools. The crazyness going in the DevOps/Infrastructure world is as bad, or worse, as the one going on in the frontend space.
It's just software that runs your software. You can't remove complexity, only abstract it. Instead of using Chef/Puppet/systemd/hand-written scripts and a bunch of other tools to run and monitor your processes, you can replace all that with K8S.
> "used only at large companies with large teams"
Actually it's even more useful with smaller teams and let me, as a team of 1, deploy a global ad platform running billions of requests a day across hundreds of servers in multiple regions. Don't mistake lack of knowledge and experience as a problem with the tool.
> "pay some provider to do it for them"
Yes, you should use a managed K8S offering. Using K8S doesn't mean you have to install and operate it from scratch.
I used to host my blog on Kubernetes for a while for that specific reason, just practice how to deploy and operate it. Then after I got bored with that simply transfered that to a static hosting solution.
But Kent is doing a disservice to people that look up to him with this blog post. The JS community already suffers from over-engineering and this is just one latest example from a community leader. now every developer who learns from Kent, will think this is the way to go.
not only does it harm newbie developers, it also harms the companies mostly startup thinking this is the way to go. interviews, workflows etc start to be centred around this way of thinking and simply all productivity gains that made startups more nimble than enterprises are lost.
maybe some of us are too stupid, to see the gains from all this architecture and wizardry, time will tell!!
I'm curious what the real/perceived issues are by others.
With all due respect to the author and the great output he's created, I agree. At minimum, I think the post should have included some context for the decisions instead of simply calling it "a modern website in 2021". The content inside isn't common, normal, or even necessary for 99% of websites, including this one.
I think this blog post is an example of the conflict between educators and industry:
Industry benefits from keeping things straightforward and getting the job done without unnecessary complexity.
Educators benefit by selling more workshops and more training materials. The more they can convince everyone that complexity is necessary, the more they can sell workshops to teach people about that complexity.
Currently I do not fail the build if the E2E tests fail. So far, I haven't been worried about deploying something that's broken and I didn't want to hold up a deploy because I accidentally busted something for the 0 users who expect things to be working.
Yet, look at the source and the first thing that pops out is:
// this is a temporary solution until I can figure out a safe way to do this on the server
if (window.location.protocol === 'http:') {
window.location.href = window.location.href.replace('http:', 'https:');
}Also surprising, of course, that an expert isn’t doing that redirect server-side.
There are multiple solutions and all of them are even simpler than what he picked.
This kind of redirect does not provide the same benefit. An attacker could just tamper with the JS to remove that code, and this could happen on any visit, not just the first.
You generally have two "servers" open, one on port 80, another on 443.
Request on port 80 get a http 301 or 302 to https://${server}${request_uri}
Usually both ports are served by the same daemon, but different vhosts/servers or whatever you want to call it
Rewrite would normally map /arbitrary/ to /something-else/ or similar things, generally transparently so the client never notices
https://github.com/kentcdodds/kentcdodds.com/commit/5a747aea...
However, bear in mind that the site is built by a popular JS influencer whose day job is popularizing frameworks and increasing demand for services of the sort he offers.
His day job is selling workshops and training materials. No matter how you look at it, he has a vested interest in promoting over-engineering because it translates to more sales of courses and workshops. That's why this blog starts and ends with calls to action about signing up and registering for workshops.
Now I have to literally ask to see a company’s codebase before taking the job so as to avoid this nonsense.
I hand-rolled my own authentication on this site. But I had a good reason! Remember all the talk above about making things super fast by collocating the node servers and databases close to users? Well, I'd kinda undo all that work if I used an authentication service.
I thought part of the benefits of auth services like auth0 is that due to them having to provided some kind of trusted token containing an identity payload (eg a JWT), you can get away without having the query the auth service per-request (assuming you can tolerate stale tokens in the event of a permission change). So the performance issue being used to justify hand-rolled auth, seems to be the result of a misunderstanding.
Facebook's now infamous implosion a few days ago harkens to this - their system is clearly NOT simple, but it works extremely well 99.9% of the time.
Many similar courses can be found for $10-$20 on Udemy.com (be sure to reset cookies/create a new account if you see higher prices. Apparently they only show discounted prices to new customer accounts.). For $600, a person could probably buy the majority or even entirety of Udemy.com's React courses -- Maybe somewhere around 500-1000 hours of content (rough estimation).
For example, this course has for 48 hours of content for $20. https://www.udemy.com/course/react-tutorial-and-projects-cou...
I've found Udemy has great content. Plus there's Youtube.
Kent, I understand that you're a solo entrepreneur and that you offer premium knowledge in your content. But I wouldn't pay more than $100. I don't think the knowledge you offer is monopolized by your course, I think it can be found through many other learning resources (books, videos, docs).
_____
Edit: just found out via another comment that Kent developed react-testing-library. That's awesome. So, Kent is likely someone who knows a ton about ReactJS, including truly expert, insider knowledge.
That said, $600 is still a crazy amount to charge to consumers. Maybe you'd charge that at an in-person seminar/workshop.
But to the internet public in general? Seems greedy.
An educational resource existing for less cost and longer duration doesn’t translate into anything real without quality ciriculum and instruction.
A lot of content on both YouTube and Udemy is…not great. And even then not necessarily curated in a certain way, etc.
Furthermore, courses like this in general often are geared at developers/engineers who are already employed and could even get reimbursement/coverage for from their employer, which offsets or eliminates the cost entirely.
CV padding developers, big names shilling for their stack, companies pushing their tech, ... The industry is a mess and it's very hard to find a job that doesn't involve dealing with it.
However, good-luck building something as complex as kentcdodds.com using that.
I don't see any content here that couldn't be done with any of half a dozen site hosting platforms, maybe require a couple of plugins. Wix, Squarespace, Weebly, even good ol' Automattic/Wordpress could do this. Perhaps clunkier, less performant, less customized, but functionally sufficient.
Remix is about making the front-end “use the platform”, progressive enhancement, SSR etc. They really strip things back to basics and it’s taking me back 20 years. I love it, and I can still write React.
Keep an eye because they have some interesting news to announce these coming weeks. I don’t work for them, just an early adopter.
While I appreciate that a lot of things have gotten more straight forward since I started mid 2000s, the cynic in me can't help but think that the primary reason for many of those tools to exist is to sell SaaS subscriptions, consultancy services, courses and certifications, not to solve a real world users problem.
I wonder what the impact of this on the field is going to be long term. The barrier of entry has gotten insanely high with all the tools you supposedly need to know. Yes of course you can still learn it the "old fashioned" way, but that's not what you will find/perceive when you look how to get started. What I see quite a bit in interviews for juniors devs is, that they know a whole lot of different tools and technologies, but often have a very shallow understanding how to solve non tutorial problems with them. Which is not per se a problem, it's something you learn on the job. But I often see a unwillingness to dig deeper, get a more profound understanding instead of immediately trying to solve a problem in one tool by adding yet another. Steadily increasing system complexity and making it harder to maintain.
Check out the size of that dependency graph for what amounts to (mostly) a personal website.
Typed Javascript for me personally has been a godsend for maintenance and avoiding stupid bugs.
To me it seems like an intentional complication of something which can otherwise be simple. Which is unfortunately somewhat common in this industry of software engineering.
It seems there might even be an interest for engineers to keep things complicated-- to gatekeep the industry, to make themselves seem more skilled/necessary so as to keep a job for longer.
(more time in a project => more money by the hour. More LoC looks like more work was done... even if the same can be accomplished with 60-70% of the code (i.e. without the type system)).
I’ve worked with NodeJS for over 10 years now and have ported many codebases from JS to TS and have never found one that didn’t contain a bug that the TS compiler found immediately, even my own carefully crafted solo projects.
Plus every type definition and annotation is basically a free self-maintaining unit test!
Precisely why I refuse to use JS for any piece of work >500loc.
Plus, there's the fact that TypeScript is developed, owned, and maintained by Microsoft.
Look into their 3 E's campaign: https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguis...
and we see it in action-- Here's an example.
Terraform CDK [1] -- It offers TypeScript as a language, but not NodeJS. Huh. That's puzzling. I wonder if Microsoft funds the project and requested it to prioritize TypeScript over NodeJS.
Additionally, in March 2020, Microsoft purchased npm.
I am saddened to see Microsoft moving into a position of control & domination in the Javascript/NodeJS ecosystem.
You miss any potential build step slogs.
as someone who has experience with ExpressJS I agree massively. Typescript you end up fighting the tooling most of the time, rather than getting work done.
To avoid all this complexity, server side render pages in html - scalable to infinity. then sprinkle js using script tags n tools like Mithril, Vue, Knockout etc on pages needed.
There's way too much empty space between some elements on the iPhone X.
If you consider this to be a showcase of (hopefully) cool new frameworks that can be used in a sensible matter on larger customer's websites, then this website is a success.
> First it determines all content changes that occurred between the commit that's being built and the commit of the last time there was a refresh (that value is stored in redis and my server exposes an endpoint for my action to retrieve it). If any of the changed files were in the ./content directory, then the action makes an authenticated POST request to another endpoint on my server with all the content files that were changed. Then my server retrieves all the content from the GitHub API, recompiles the MDX pages, and pushes the update to the Redis cache which Fly.io automatically propagates to the other regions.
> This reduces what used to take 10-25 minutes down to 8 seconds
If my team reached the point that simple website deploys were taking 25 minutes or required long chains of API calls between bouncing between various internal and external services, I’d start to worry about what sort of complexity we’ve built into our stack. On one hand their solution is neat, but on the other hand I can’t help but worry about how we got here in the first place. More importantly: Why? What does this complexity give us that we couldn't achieve with a simpler solution? Imagine being asked to take over this project and having to understand the long chain of events required just to get new content into the website.
I understand these articles are meant to be a showcase of technologies and how they can be used, but I’ve also seen a lot of otherwise simple webdev projects spiral into unnecessarily complex projects like this. I've also mentored a lot of juniors who think their companies are doing something wrong if they're not building complexity-first web projects or they're not using a long checklist of the hottest webdev tools.
These complex projects are fun to work on and learn, but it becomes a huge burden to maintain. The webdev world moves so fast that a project built on 15 different trendy projects will inevitably have some of them fall out of favor or become deprecated each year. Any long-term project like this will inevitably start losing time to constant refactoring and rebuilding around the newest trendy components each year.
It’s critically important for these teams to have some oversight in the form of someone asking pointed questions about whether or not each additional layer of complexity is truly necessary. Some times the most elegant solutions are also the most painful maintenance nightmares down the road as the original architects cycle out of the company.
Side note: As much as I appreciate all of the great free learning resources made available by authors like this, I can't get past the inherent conflict of interest involved with educators advocating for complex projects and then selling learning materials to understand them. This seems especially common in the webdev world where the popular tooling changes from year to year and can require a lot of learning to get it right. Sure enough, this blog post ends with a call to purchase tickets to learning workshops to understand what's going on here:
> It's been a ton of fun and I'm excited to put my learnings into blog posts and workshops to teach you the specifics of how I did this stuff so you can do it too. In fact, I've already scheduled some workshops for you to attend! Pick up tickets now.
As always: Caveat emptor. Complex projects are fun, but don't assume that a modern website must be complex.
So it's a makefile with rsync. Gotcha.
Top companies pledge to use newer technologies as a carrot to lure in devs as older technologies fall out of style, so the expectation is then placed on developers to learn new tech in order to get those top jobs. I see this as the dark side of "always be learning new things", because we often justify the need to learn these new technologies by translating them into job opportunities.
Having been on both sides of this (IC and hiring manager), I've realized it goes both ways: A lot of candidates assume that unless your company is using the latest technologies, it's not a good place to work. This drives a lot of team leads and engineering managers to try to play Buzzword Bingo to make their project look most attractive to candidates. Candidates see this and assume that they also have to play Buzzword Bingo to be compatible with those most attractive jobs. It's a vicious cycle.
This might be my personal opinion, but if you write modular code and dedicate about 40% of your roadmap to refactor, commiting code upstream, and engineering related tasks you won't run into near as many long term maintainability issues.
> "I can't get past the inherent conflict of interest involved with educators advocating for complex projects and then selling learning materials to understand them."
...or people just building in job security.
If stopped reading at that point :/
There's probably no need for Typescript in simple projects that are less than a few hundred lines of code, but the immense spider web of dependencies this blog features becomes unmaintainable if you don't use proper type validation. Remembering what properties are in what objects in a Rube Goldberg machine like this are simply impossible.
I appreciate languages like Javascript, PHP and Python for their ease of use, but I don't think they're well suited for any complex project.
I used to get annoyed by TypeScript too when I first started using it—I felt like it was slowing me down and making me unproductive. But this is only because I tried to use TypeScript without really understanding how to use it effectively (which will make you unproductive with _any_ tool).
Once you work long enough with TypeScript, going back to pure JavaScript feels like hell.
After using it for five years I can confidently say I was wrong.
I wouldn't even consider working for a company still using regular Javascript.
500 - Oh no, something did not go well.
"/blog/how-i-built-a-modern-website-in-2021" is currently not working. So sorry.
Man it's 21 (direct) dependencies plus six services. Great for demonstration but please don't hang yourself with the dependency rope so easily (in real projects).
uid demo pwd demodemodemo
If this is serious I'm horrified that you went down this path. Having requests going to some regions you're not happy with is not a reason to compromise your users' security by handrolling your own flow. What's awful is that there are people who will read this and think it's a perfectly reasonable thing to do.
You are not a security expert, that much is clear. Because you wouldn't have uttered those first two sentences in the first place.
"Context Before we get too far into this I want to make my one thing clear. This is not just some developer's blogfolio site. It's a platform with unique constraints and requirements. So before you start claiming that I've over engineered my site, keep in mind that the term "over engineered" is relative and you may not have the context to make that kind of judgement. I was extremely thoughtful about the architectural decisions I've made. Whatever tools or tech you're more familiar with that you think would be better suited for this site I'll bet you that I evaluated and decided it wouldn't work for my use cases. Thank you for coming to my site, Hacker News visitor "
On one hand, people underestimate the complexity of building production-ready web applications. So, any "why not just a index.html" comments show a clear lack of understanding. However, it's not /that/ complex that we couldn't have a solution to get started with best practices on an prod-ready environment in just a few clicks.
I can't really tell the difference in this thread through jealous snide side comments and those which just lack understanding of large production applications.
Of course the guy is going to push tools he has courses about, I wouldn't expect different from anybody else.
I put all my cool code there and I over engineer it to death. It's awesome - it's fun - it's what you should do if you love coding. Guess what - I also have a table full of electronic projects, I've made unfinished games, I've done hackathons, it's great and we should embrace that.
Perhaps Kent Dobbs likes experimenting with new technology and trying new stuff. Perhaps his own personal web site is a place where he can do whatever he wants.
If you criticize him for that... well let's just say, I doubt your ability to code - and you are banned from my nerd club. If you don't take joy in an overengineered personal web site - then you are doing it wrong.
Seriously, speed runners spend months trying to save milliseconds on a mario speed run and you want to whine about a software engineer taking joy in his craft...
Ok, that's my rant.
I support freedom, I support the free web, I support the proliferation of code and over-engineered solutions.
Is it over-engineered? Maybe. Who cares. HN is so worried about juniors taking his architecture as gospel. Does the liquor store clerk have to tell me not to drink too much too fast? Juniors are going to over-engineer something regardless, it's one of the most valuable lessons they'll learn the hard way. The rest of us can read this piece, think critically, and maybe learn some new things.
[1] https://github.com/kentcdodds/kentcdodds.com/blob/main/index...
Yes, juniors tend to over-engineer. Kent C. Dodds is not junior -- he is a self-described "world renowned speaker, teacher, and trainer" in this field.
Improving the world w/ quality software · Husband, Father, Latter-day Saint, Teacher, OSS · http://TestingJavaScript.com · http://EpicReact.Dev · Be Kind
A considerable part of the stack is either reasonable or a consequence of one.
Example, a usable Tailwind integration always comes with PostCSS. And that with next to zero effort. Same goes with the testing setup.
Now, if only I knew why on earth people use Remix.