This guy is a snake oil salesman most likely. This is an utterly contrived and overly complicated setup to run a personal site / signup form for paid lessons. Any experienced engineer worth their salt will eye roll at this but I know junior engineers who would just eat this up.<p>"Hi, I'm Kent C. Dodds. I'm a world renowned speaker, teacher, and trainer ..." - <a href="https://kentcdodds.com/info" rel="nofollow">https://kentcdodds.com/info</a>
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.<p><a href="https://kentcdodds.com/discord#reasons-to-join" rel="nofollow">https://kentcdodds.com/discord#reasons-to-join</a>
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.<p>Then onto his LinkedIn (<a href="https://www.linkedin.com/in/kentcdodds/" rel="nofollow">https://www.linkedin.com/in/kentcdodds/</a>). 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.<p>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.<p>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.
Sorry, this reads like a The Onion piece for developers. It looks like pure nightmare. There's so much complexity that simply doesn't need to be there.
React Testing Library and other testing libraries from Kent are a godsend.<p>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.<p>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.<p>maybe some of us are too stupid, to see the gains from all this architecture and wizardry, time will tell!!
<p><pre><code> 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.
</code></pre>
I’m having trouble forming the words for how I feel about an apparently influential author promoting the sort of Rube Goldbergesque overcomplection in the rest of the article, while downplaying the single piece of value this CI pipeline could be delivering.
This seems insanely over-engineered.<p>Yet, look at the source and the first thing that pops out is:<p><pre><code> // 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:');
}</code></pre>
I've been on HN long enough to realize that the majority of comments here are going to inevitably devolve into a discussion of the sheer complexity and breadth of tooling listed here.<p>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.
<p><pre><code> 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.
</code></pre>
This is a great example of how fundamental architecture decisions limit your subsequent decisions, and it’s your job as a designer to make sure that the final result makes sense and reflects good tradeoffs, not just the state as you go. Hand-rolling auth (a real risk) so you can use this unnecessary distributed deployment scheme (no real value) is a bad decision.
I'm glad to see the hacker news community shitting on this. I deal with far too many developers like the OP on a daily basis, sometimes their crappy over-engineered ideas come to fruition and we end up paying millions to maintain it
OK, I had no idea who this person was. But then I glanced over the piece, then at the rest of his site, and then I scratched my head over why something simple like Wordpress wouldn't suffice. It seems to be a standard "about us" site and links to the courses go to pages with just a Stripe checkout workflow. What is the point of all this fuckery other than to convince people that all these things are needed and so they should buy his courses?
$600, for a React course, are you serious? I know it's 20 hours of content, but so are many Udemy courses.<p>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).<p>For example, this course has for 48 hours of content for $20.
<a href="https://www.udemy.com/course/react-tutorial-and-projects-course/" rel="nofollow">https://www.udemy.com/course/react-tutorial-and-projects-cou...</a><p>I've found Udemy has great content. Plus there's Youtube.<p>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).<p>_____<p>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.<p>That said, $600 is still a crazy amount to charge to consumers. Maybe you'd charge that at an in-person seminar/workshop.<p>But to the internet public in general? Seems greedy.
Reading stuff like that makes me happy I've left web development behind me, and things like that were a big factor, the inflation in complexity has been insane over the last decade and is absolutely not justified.<p>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.
Reading all the hype for Remix, a paid closed source tool, and still not knowing what it is really makes me jaded. I’d urge the authors to consider the signal to noise ratio they’re creating, and whether they are helping others vs themselves with this hype.
It seems web development devolves more and more from "use the right tool for the job" and KISS (not that it ever fully was either) to "use all the tools you can find for the job" and focus on process instead of product.<p>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.<p>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.
Curious - why aren’t simpler frameworks like htmx (<a href="https://htmx.org/" rel="nofollow">https://htmx.org/</a>) more common or
gaining traction? It feels unnecessarily complex to have to use so many modules to build a website today. Especially if it doesn’t need dynamic content.
Just for funs, ran this site's package.json through npm.avanka.com: <a href="https://npm.anvaka.com/#/view/2d/https%253A%252F%252Fraw.githubusercontent.com%252Fkentcdodds%252Fkentcdodds.com%252Fmain%252Fpackage.json" rel="nofollow">https://npm.anvaka.com/#/view/2d/https%253A%252F%252Fraw.git...</a><p>Check out the size of that dependency graph for what amounts to (mostly) a personal website.
I like the large text on the homepage. The large graphics with the snowboard koala takes a bit too long to load (or render?) for my taste. But then again the colour of the sweater and the snowboard changes every couple of reloads, that's worth waiting for, right?<p>There's way too much empty space between some elements on the iPhone X.<p>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.
Articles like this are equal parts fascinating and worrisome. Fascinating because as a developer I love to see elaborate systems built to accomplish a goal. Worrisome because as a manager I have alarm bells going off in my head when I start reading about systems that get so complex that they have to add even more complexity just to tame problems introduced by earlier complexity:<p>> 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.<p>> This reduces what used to take 10-25 minutes down to 8 seconds<p>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.<p>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.<p>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.<p>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.<p>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:<p>> 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.<p>As always: Caveat emptor. Complex projects are fun, but don't assume that a modern website must be complex.
All i humorously get is:<p>500 - Oh no, something did not go well.<p>"/blog/how-i-built-a-modern-website-in-2021" is currently not working. So sorry.
The combination of caching Postgres queries (because you are making over 30 of them per page), but still deploying everything to 6 distributed regions is just perfect <i>chef's kiss</i>
Once again Kent omits to warn his audience that such a codebase has a performative intent, and should be considered a weird exercise of thought rather than a model to follow.
I'd like to thank the author of the site for the entertainment (indirectly) provided in the HN comments. The rage is completely understandable.<p>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).
> Yup, that's right... 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. Every request would have to go to the region that provider supported to verify the user's logged in state. How disappointing would that be?<p>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.<p>You are not a security expert, that much is clear. Because you wouldn't have uttered those first two sentences in the first place.
He added a paragraph in response to the HN comments:<p>"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 "
This is ridiculous that there's no good way to have a production ready environment without all this plumbing. Redwood comes close but still missing many things.<p>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 love my overengineered web site / playground. Yes, I hid a text adventure in the site header. Yes, it is full of stuff that no-one will care about. It's my art and my passion.<p>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.<p>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.<p>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.<p>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...<p>Ok, that's my rant.<p>I support freedom, I support the free web, I support the proliferation of code and over-engineered solutions.
Since I saw almost no positive comments I'll throw my hat in the ring. I love stuff like this. I learned a handful of things to toss in my back pocket for future projects/hacking. Remix looks fascinating, albeit young and closed-source. I've been wanting to play with Prisma & MSW for a while, so it was great to see how he used them. His DX looks top-notch, I love hacks like his "server side HMR" [1]<p>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.<p>[1] <a href="https://github.com/kentcdodds/kentcdodds.com/blob/main/index.js#L88" rel="nofollow">https://github.com/kentcdodds/kentcdodds.com/blob/main/index...</a>
Truth be told, I had a chuckle myself. Then I saw this predictable HN whine.<p>A considerable part of the stack is either reasonable or a consequence of one.<p>Example, a usable Tailwind integration always comes with PostCSS. And that with next to zero effort. Same goes with the testing setup.<p>Now, if only I knew why on earth people use Remix.