How I built a modern website in 2021(kentcdodds.com)
kentcdodds.com
How I built a modern website in 2021
https://kentcdodds.com/blog/how-i-built-a-modern-website-in-2021
161 comments
Well, here’s the thing, the pragmatic developer is not his market. It’s the newbies or those who are deeply associating their new career with the identity of a ‘legit’ developer. This is the group that will pay him.
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.
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.
You put into words my exact experience with his influence on someone in my team a while ago. It was exhausting to have someone add complexity to our react codebase i.e. through render props + “accessor pattern”. It had a significant cost in code reviews and refactors.
I'm planning on replacing the TodoMVC example and use a more real-world example.
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).
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).
As a front-end myself with my share of experience (Senior-Staff level), I've found a way of answering this "I’m not sure how any of us can solve it" is by building credibility on yourself and on your tools. It's a bit of an uphill battle, but def doable.
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.
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.
The problem is by the 3rd-4th project you are brought on to help, you pretty much become jaded. How many times can one deal with it without losing patience?
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.
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.
Kent C Dodds is well known in the JS community. I've heard great things about his testing libraries, but he has a weird "dev celebrity" thing going on (EDIT: which, btw, is not rare in the JS/React/Node world). I'm sure that's just necessary for marketing himself as an educator since that's his main source of revenue.
Kent is a great resource in the frontend community, giving a way tons of content for free, including several very popular open spurce libs. Nor sure why you’re being so negative towards somebody you obviously don’t know
Because every inch of this website is dripping with scummy MLM language around his courses and we as an industry have seen scams proliferate around preying on people trying to make it in tech. https://cryptobriefing.com/youtuber-techlead-accused-of-scam... for ex. It offends me morally.
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.
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.
Honestly, and I mean this as no insult: it sounds like you have been some kind of past bias/trauma on this subject or are else taking a really pessimistic view of these things.
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.
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.
But it also feels like there was a similar discussion on his other articles just a year ago on /r/reactjs, which I’m going to generalize and say might be less jaded than HNers:
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.
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.
> the myriad of newer alternatives that boil Redux down even more to something even simpler)
Going on a tangent here, could you suggest any notable library replacing redux to look at?
Going on a tangent here, could you suggest any notable library replacing redux to look at?
https://github.com/arnelenero/simpler-state
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.
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.
There are thousands of people in his Discord going through his courses. He’s simply helping people form remote study groups, like students do in school.
[deleted]
I've never used any of his educational content but some of his open source libraries are top notch. Some of his blog posts have been influential and very pragmatic/sane.
You may be right about the selling tactics but the ad hominems are in comically poor taste.
You may be right about the selling tactics but the ad hominems are in comically poor taste.
No, this isn't it. What he did was basically build a production-ready webapp for his own personal blog. Was this overkill? Maybe. But when you're used to work in that kind of prod environment, you want to reproduce it when building any other projects. So I think this isn't so much a snake oil salesman crap but more about the current lack of good solution to get this kind of environment ready in a few clicks.
I thought it was just a parody
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.
I have to agree here, this article really goes out to show the perceived state of JavaScript & web development. over-engineered is the key word here
On the other hand, a lot of people on HN promote Kubernetes, even for relatively basic sites/servers/APIs
Kubernetes is a way to handle complexity with infrastructure and operations that is codified and implemented as a single standardized and portable solution. Much of what K8S does is replace what you would be doing manually or by tying together many other tools yourself.
That's completely different than taking a simple blogging site and turning it into some distributed monstrosity.
That's completely different than taking a simple blogging site and turning it into some distributed monstrosity.
Kubernetes is a low level tool which should be used only at large companies with large teams to support it and build all the required tooling around it.
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.
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.
Kubernetes provides a standardized way to deploy application artifacts to multiple servers, and handles monitoring, logging, process management, storage, networking, security, isolation, high-availability, rolling deployments, and other concerns in a industry-standard way that is portable across providers.
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.
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.
GCP's Autopilot k8s is basically point-and-click. Literally takes few minutes to get up and running. It even creates CI/CD pipelines for you.
> Much of what K8S does is replace what you would be doing manually or by tying together many other tools yourself
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.`
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.`
There are many CI/CD pipelines that deploy to K8S.
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.
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.
Looks like he is selling courses(have to justify those prices somehow) and simple stable boring stuff doesn't sell ;)
He's selling courses on the technology he used, so the site is both a demonstration of and lesson in what he teaches. It's a functional portfolio that seems intended to demonstrate that the author and instructor understands what he is asking you to pay him to teach.
Understanding when and where to deploy technology is much more important than just using everything. Sadly that's much harder to teach.
Agree 100%. By erecting this over-engineered gold-plated edifice the author has demonstrated knowledge, but not wisdom.
Just out of curiosity, how would you design a distributed website like this? How can this be done simpler?
Well since this looks like a blog, either using a blogging platform, or a static website generator hosted on either a static website platform(1) or something like lambda + a cdn
(1): https://azure.microsoft.com/en-us/services/app-service/stati...
(1): https://azure.microsoft.com/en-us/services/app-service/stati...
The article explicitly mentions needing to support writes with a globally distributed user base. This is not a static website.
Not everything in a static webapp needs to be static, just push most static things to the CDN and render some things like "user details" on the client... it just works out so much simpler.
and the login for your users?
By not making it distributed.
What is missing from the description apparently is the SLA for the site's downtime.
If it's really low, I can imagine why it was made distributed. Otherwise, I'd see that as a demo and an exercise.
If it's really low, I can imagine why it was made distributed. Otherwise, I'd see that as a demo and an exercise.
> What is missing from the description apparently is the SLA for the site's downtime.
> 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.
> 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.
While I agree in principle, a database-driven distributed site would need a bit more than cloudflare.
(For a personal informational site I'd take a static site generator.)
(For a personal informational site I'd take a static site generator.)
It is the author's own website, there is no contractual SLA.
In any case, with a distributed architecture there are many parts that can break. Fewer moving parts means fewer broken pieces.
In any case, with a distributed architecture there are many parts that can break. Fewer moving parts means fewer broken pieces.
That “distributed” quality itself is a choice that introduces complexity. There are many sites that deliver the same or greater level of value to users, and use a “boring” architecture and deployment.
Do you mind sharing some? Most websites I can think of are either highly distributed (e.g. Facebook, Netflix) or their customer base is geographically limited (Yelp).
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.
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.
Those are all sites with 1000s of engineers, real-world use, and actual evolutionary pressure driving their features. You want to compare to essentially static sites with some light user statefulness.
This guy's site is not netflix nor facebook, nor is he 10k developers to support those architectures.
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.
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 offtopicness but could you please email [email protected]? I want to send you a repost invite.
My email is the same as my username at the usual proton mail domain.
Sorry for my dumbness, but not sure what a repost invite is. Something good I hope XD.
Thanks.
Sorry for my dumbness, but not sure what a repost invite is. Something good I hope XD.
Thanks.
Thanks, I'll send it!
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 :)
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 :)
Done. Thanks!
At least half of the gains can probably achieved by just rolling a distributed redis setup and not distributing the PostgreSQL database. This should cover most non-personalized read operations which on this type of site should be most of them. It also seems like the database distribution is an attempt to solve a problem of his own making. He states that each blog posts page view needs 30 database queries in the background. This to me suggests an inefficient data structure or complexity for complexity’s sake. Heck, he could probably even achieve 80% of what he’s trying to do by delivering selected slow but static queries from edge computing KV stores without having any further distributed backend or database servers. But ofc this whole project is a sales pitch and he would get the attention he’s receiving with a simple Django+Postgres+Redis setup in a single region with just basic CI/CD.
It doesn't need to be distributed. It's a mostly static site with some dynamic parts.
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.
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.
[deleted]
Ruby On Rails
This was my first reaction. But then I can also understand why you would use your own website as either an exercise or a showcase of all these techs.
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.
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.
Just imagine all the newbie and junior devs following the ideas this person puts in their heads. That's how you land a new job just to find out the landing has more engineering than the Mars Rover.
Nailed it. The whole time I was reading I had this uncanny valley feeling of like “this is so close to satire but not quite” waiting on the needle to drop that sealed it as satire, but it never came.
React Testing Library and other testing libraries from Kent are a godsend.
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!!
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!!
> 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.
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.
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.
Everything RTL does was possible in Enzyme too. It would have been possible for him to make PRs to remove problematic parts of Enzyme, or create a wrapper strictly over it, if he was optimizing for the things you said
I've used Enzyme for years. I do have to write some small utility wrappers around but I don't overall have many issues with it.
I'm curious what the real/perceived issues are by others.
I'm curious what the real/perceived issues are by others.
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.
Hey he correctly identifies 0 users 0 problems
This seems insanely over-engineered.
Yet, look at the source and the first thing that pops out is:
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:');
}Surprising that with all that infrastructure he’s not compacting/obfuscating his JS.
Also surprising, of course, that an expert isn’t doing that redirect server-side.
Also surprising, of course, that an expert isn’t doing that redirect server-side.
Do browsers even allow this? I thought this would display the red page "INSECURE CONNECTION" warning, I wouldn't think it would run this Javascript too...
He fixed it promptly based on HN feedback!
https://github.com/kentcdodds/kentcdodds.com/commit/5a747aea...
https://github.com/kentcdodds/kentcdodds.com/commit/5a747aea...
Ironically, isn't the server-side feature usually called "rewites"?
No, it's redirect.
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
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
To be fair, doing it client side like this is so much easier than setting up all the rewrite rules server side. It's actually kind of funny he chose the least complex route here considering everything else about his site is overly complicated.
The point of redirecting to HTTPS is so someone cannot MITM your traffic. HSTS ensures there's only one chance for that to happen as your browser will remember the HTTPS redirect.
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.
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.
This should be done server-side and is a single line with most frameworks or web servers. It actually highlights the central issue here being frontend devs and practices trying to reach into the backend without any experience or knowledge, resulting in an over-complicated mess while solving no real problems.
What rewrite rules? Caddy does it for you automatically. With nginx it's a single line in the config file. Or throw your site into HSTS preload (ok, you'll have to add a single header to the config) and any modern browser won't even try HTTP.
There are multiple solutions and all of them are even simpler than what he picked.
There are multiple solutions and all of them are even simpler than what he picked.
To add to the sibling comments (not downvoting): if you have a HTTP site served by Apache and use the Apache plugin for certbot to obtain a Let’s Encrypt-signed certificate, certbot also does a good job generating the Apache configuration to enable redirects to the HTTPS version.
This is a one liner in NGINX...
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.
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.
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.
> 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.
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.
Many of us have a vested interest in pushing back against this industry because it favors hiring younger, less experienced people who will advocate for these systems in the workplace. For many of our own sanity, we have to push back somewhat.
Now I have to literally ask to see a company’s codebase before taking the job so as to avoid this nonsense.
Now I have to literally ask to see a company’s codebase before taking the job so as to avoid this nonsense.
You seem to be pointing at the same problem, just under a different (and reasonably interesting) angle.
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.
The auth thing was the main thing I questioned (aside from over-engineering, but my own site is guilty of that too).
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.
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.
Or you could just stand up Keycloak along with your backend services
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
As a bit of a pushback to this - doing the opposite and not considering optimizations and edge cases is perhaps a major source of so many YC startups (and any startups out there that need tech in general) fail when they reach any sort of critical mass - simple is always good, if it actually works at scale.
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.
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.
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?
WordPress? Really? I can think of a thousand reasons not to use WordPress, such as horrible, outdated security practices, constant DDoSing of your site because of the aforementioned, having the overhead of jQuery, not wanting to use PHP because it's not your preferred language, not wanting to use old, outdated spaghetti WordPress code even if it were, etc...
$600, for a React course, are you serious? I know it's 20 hours of content, but so are many Udemy courses.
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.
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.
I don’t know what gives you the impression that course duration somehow equates to course quality.
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.
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.
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.
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.
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.
I honestly cannot tell if this is satire or not.
Hello Poe's law [0].
[0] - https://en.wikipedia.org/wiki/Poe%27s_law
[0] - https://en.wikipedia.org/wiki/Poe%27s_law
Boy some days I miss making a webpage with a simple index.html and five pages...
That still works! No one is stopping you from opening a text editor and writing an index.html document then drag-and-drop through an FTP client to a production server.
However, good-luck building something as complex as kentcdodds.com using that.
However, good-luck building something as complex as kentcdodds.com using that.
What's complex about a blogging/marketing/workshop site? Or did you forget a /s?
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.
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.
There are some images, text, some fancy JS menus, and some small animations. With the exception of the embedded videos, there's nothing here that can't be done with some static pages.
True, but there's also nothing here you couldn't do with a pretty standard Django or Rails setup.
...except maybe speed. But this is more about Python and Ruby lacking a standard and efficient JIT, unlike JS, and not so much about architecture.
This so much. How I do "modern website": one HTML file, linking a typescript lib (if required). Optionally said page is generated by ASP.net Core. Database if required. So, ranging from 1 to 4 tech (not counting CSS), only one being compiled.
You can still do that today. I did!
https://0x85.org/orgsite.html
https://0x85.org/orgsite.html
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 most of the concerns in this thread are related to devops which is not something Remix influences.
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.
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.
Oh, they announced it just now https://twitter.com/remix_run/status/1447649474038222851
No usable information on their website either. A wall of text followed by pricing.
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.
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.
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.
Curious - why aren’t simpler frameworks like htmx (https://htmx.org/) 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.
This video actually does a pretty good job of explaining the state of web today. He goes into why frameworks that stream html as updates are insufficient. The GitHub UI for example does this and its full of inconsistencies. https://youtube.com/watch?v=860d8usGC0o&feature=share
Just for funs, ran this site's package.json through npm.avanka.com: https://npm.anvaka.com/#/view/2d/https%253A%252F%252Fraw.git...
Check out the size of that dependency graph for what amounts to (mostly) a personal website.
Check out the size of that dependency graph for what amounts to (mostly) a personal website.
"helps save the trees" is where i lost it completely. Oh my god, we _deserve_ all of this hellscape.
The amount of koolaid around TypeScript is really something
Genuine question: what's up with it?
Typed Javascript for me personally has been a godsend for maintenance and avoiding stupid bugs.
Typed Javascript for me personally has been a godsend for maintenance and avoiding stupid bugs.
I haven't had trouble with maintenance or avoiding bugs with NodeJS. I don't see justification for putting in 30-40% more time and effort for the same result.
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)).
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)).
If you work by yourself this can be true. But it’s not that different from saying you don’t need to write tests because you don’t have trouble with bugs! That might be true but it doesn’t make it a good idea.
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!
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!
> I don't see justification for putting in 30-40% more time and effort for the same result.
Precisely why I refuse to use JS for any piece of work >500loc.
Precisely why I refuse to use JS for any piece of work >500loc.
Really? Why do you say that? I use it extensively in large Electron apps. It's saved me from myself so many times and it makes JS so much more structured. I dunno, I think it adds things javascript missed because it was never intended to be such a significant language: it was designed for handling buttons and submitting forms, but it is so much more important than that today. It's the hands-down best cross-platform language in existence.
[deleted]
no lies, told: I like this quote from SparkJava
> Lately, a lot of server-side web development has been taken over by NodeJS, but a growing number of NodeJS developers are using TypeScript and other statically typed languages that compile to JavaScript. Why not go all the way and use a language that was actually designed with types, and intended to run on the server-side? You also get all the benefits of running your application on the JVM, where libraries aren’t deprecated every day. If you’re coming from ExpressJS, then Spark’s syntax will feel very familiar, and unlike a lot of JavaScript web frameworks, Spark won’t be deprecated tomorrow.
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.
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.
I agree. While TypeScript is good for any JavaScript project, Node based APIs have always felt like the tooling has lagged behind other frameworks and languages. I've since really started to enjoy .NET for backend tasks - but of course there are many other good options.
Pro-tip: skip using TypeScript the lang, and use it instead as a static type checker. Define all your types via JSDoc, and write JS normally: https://www.typescriptlang.org/docs/handbook/jsdoc-supported...
You miss any potential build step slogs.
You miss any potential build step slogs.
I agree. It's so weird to me that a developer would choose to write 30-40% more code than necessary. I love the simplicity of NodeJS/Javacript itself.
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.
[1] https://github.com/hashicorp/terraform-cdk
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.
[1] https://github.com/hashicorp/terraform-cdk
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?
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.
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.
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:
> 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.
> 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.
> > 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.
So it's a makefile with rsync. Gotcha.
So it's a makefile with rsync. Gotcha.
I completely agree with you that an architecture like this would likely become cumbersome to maintain as product requirements shift. That said, I've noticed that new tech kinda feels like an arms race in terms of recruiting.
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.
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.
> 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.
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.
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.
Like usual, our society operates in extremes. When I first came into tech businesses would use old, cumbersome stacks because refreshing every 5 years was of no benefit to business oriented people. A good chunk of businesses (still) don't really like the word refactor, so they don't integrate a certain percentage of it into the roadmap. Then engineers got tired of maintaining software that was on life support without acknowledgement, and the competition for engineers took over. Now you have incredibly new relatively untested stacks and tech being used as a recruitment tool.
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.
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.
Additionally -- as a management type person, whatever you want to call the role -- you should be concerned about if people quit, can someone else just step in off the street and take over that role?
> "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.
> "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.
> TypeScript: Typed JavaScript (necessary for any project you plan to maintain)
If stopped reading at that point :/
If stopped reading at that point :/
The introduction of Typescript at my job has made developing code so much better.
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.
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 wouldn’t add python to that list as it supports decent typing (even though it’s not forced one you by default). When you disallow untyped methods and functions with mypy, the resulting code is quite clean and maintainable imo. And I wouldn’t call a language that’s used by probably the majority of all large web projects, including Instagram for example, in some way or other “not well suited for any complex project”.
I don't understand this sentiment. TypeScript is fantastic, and I can't help but think that all of the people hating on it are frustrated because they haven't taken the time to properly learn it or understand why it's constantly complaining about the code they write.
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.
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.
I used to feel the way you do (absolutely despised TypeScript).
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.
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.
He's about the launch his TypeScript training course...
All i humorously get is:
500 - Oh no, something did not go well.
"/blog/how-i-built-a-modern-website-in-2021" is currently not working. So sorry.
500 - Oh no, something did not go well.
"/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 chef's kiss
Caching queries makes sense when deploying to distributed regions right? Trying to understand why this is wrong apart from the unneeded complexity.
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.
Edit - he added a warning shortly after I posted the parent comment: https://twitter.com/kentcdodds/status/1447283294681194496
I'd like to thank the author of the site for the entertainment (indirectly) provided in the HN comments. The rage is completely understandable.
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).
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).
This is what overengineering looks like
I’m getting a 500 error which is not a good sign.
Which is amusing because there's a whole section on how it's deployed across six regions globally for performance and reliability.
lol, HTML isn't in the "primary technologies". That must be it's modern.
Please build a login with just HTML.
Don't do it without: https://demo.mro.name/shaarligo
uid demo pwd demodemodemo
uid demo pwd demodemodemo
> 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?
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.
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.
He added a paragraph in response to the HN comments:
"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 "
"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.
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.
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.
Yes, my feeling exactly - especially when some of the "manager" level comments assume all tech should be infinitely fast when being shipped / released. Releasing to web is usually possible to optimize (in terms of how long it takes) with many strategies, but don't even get me started about mobile... the store approvals take anyway 24-48 hours!
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 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 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.
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.
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.
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]
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...
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...
> Juniors are going to over-engineer something regardless, it's one of the most valuable lessons they'll learn the hard way.
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.
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.
Please don't forget, he is also a SAINT no less. Directly from his github profile:
Improving the world w/ quality software · Husband, Father, Latter-day Saint, Teacher, OSS · http://TestingJavaScript.com · http://EpicReact.Dev · Be Kind
https://github.com/kentcdodds
Improving the world w/ quality software · Husband, Father, Latter-day Saint, Teacher, OSS · http://TestingJavaScript.com · http://EpicReact.Dev · Be Kind
https://github.com/kentcdodds
Downvoted for not conforming to the hive mind, I suppose.
This is just advertising for a framework you have to pay for if you want to use.
[deleted]
Truth be told, I had a chuckle myself. Then I saw this predictable HN whine.
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.
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.
Always going to end up with a framework for React. Otherwise all you have is an SPA.
[deleted]
"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.