- Some serverless hosting - Some database provider - Some auth provider - Some other service, etc
In the past you just rented a simple VPS or shared hosting, setup all by yourself and have just one provider for everything, nowadays I read that auth it's very hard and you should not do it and instead use some auth provider (Auth0, etc).
I remember the good old days with php, just upload your file and it worked, now they try to replicate that experience but with dozens of providers.
I also think that the advice around Authentication is often misguided. For simple cases it's not that hard to add authentication without a separate service. There is too much scaring the newbies around that topic, when they are probably about as likely to mess up authentication when they try to configure an excessively complex library compared to implementing basic session authentication with the tools their framework provides.
The great big irony here is just that "serverless hosting" is just an extremely silly new name for "shared hosting". The basic economics are the same: instead of paying for a whole server, pay for what you use, then share the remaining resources with other sites.
The new serverless hosts aren't just trying to replicate the "good old days" experience, in some cases they've inherited it. They've also just had the bad luck of hindsight from past shared hosting model problems: insecure FTP is dead (so there's much less of a feeling of "just copy the files over"), allowing direct crontab editing is known to be dangerous in shared hosts so serverless options need their own (often extremely custom) timed kickoff DSLs, hosting static files and application files in the same place is known to cause accidents so there's a greater separation in static hosting and serverless applications, and so forth. A lot of those same complications happened to a lot of the "classic" shared hosts, too. (Which is why many of those entrenched to specialize in known applications over time, cPanel anything you want as long as it is Wordpress or Drupal or one of the other six blog apps the host vetted. The disappearance of "shared hosting" wasn't just that modern development got complicated but that modern shared machine security got harder.)
Someone stripped off that nuance in trying to come up with a concise buzzphrase for code that expects ephemeral access to an arbitrary server.
The only reason we don’t do it anymore in the cases where that would be enough and instead overengineer everything is because others will look us down.
The article reads like satire. I can’t tell if he’s making fun of the hoops you have to jump through to make a “modern web app”.
You are just saying it's not good, that you would not advise to follow him, etc...
> The proliferation of his perspective has, quite literally, been a pain in my ass daily trying to re-teach misguided fundamentals
Again can you give an example?
I feel like he gives sound advice, but I just recently discovered him.
Even a C# developer building with aspnet has to reach out to many of these tools: grafana, some hosting service, some log/error monitoring tool.
But at the same time, I think a lot of comments here are pointing at the glaring reminder of how obscenely complex development for the web can be in the JS ecosystem (for new or non-js devs). Why point new engs to remix, prisma, mailgun, insert 3rd party tool when it’s so much better to give them the Ruby on Rails approach? Aspnet, Ruby on Rails, and similar frameworks in all languages including JS frameworks incorporate nearly all the tools mentioned but without requiring someone to wire it up themselves (or to understand the wiring).
Absolutely agree, this has nothing to do with Kent.
> but without requiring someone to wire it up themselves
That's the whole point of the stack - that you don't need to wire all of that tech yourself.
His preferences are always bleeding edge, hip things. And that's not the kind of stuff you build on when you want to buck up and ship an idea.
It might be good stuff, but using what you know and what is stable is the only choice when you're trying to get things done. SQLite, yes. LiteFS on fly.io? Why? Just run bloody SQLite on a server and get it over with.
He historically caters to a beginner crowd, but totally skips fundamentals - then we all get know-it-alls that we have to bring back down to reality.
It's not so much the technology he likes, but the way he pitches it is extremely problematic. He pitches niche, complicated stuff and tries to pass it off as basics.
No thank you.
I see, thanks for explaining.
> LiteFS on fly.io? Why?
He talks about this in his conference talk - to improve the UX. If you deploy to fly.io "edge" or whatever is that, you will get local reads no matter where you are.
Having worked for several years at a startup on rails, I can really confidently say the DX experience with Remix is no match..
I don't understand people in this thread complaining about niche complicated stuff when at the end of the day.. it's all just javascript, there's no magic..
The amount of abstractions, opinions, and siloed "you kinda just have to know that's the way it works" sort of knowledge that come with working with Rails is far beyond that of working with Remix. Would be curious to know how much time folks here have actually spent building with Remix. It's just good, give it a try.
Personally, I've learned a lot from Kent. I think his content is mostly quite good, I also don't find him to be someone who's sole mission is to make money and sell his product like a lot of folks in this thread have claimed. He gives a lot, for free, and contributes a lot.
Remix might be good if you want to use React, but it's ages away from what the Rails or Laravel ecosystem will provide you. Things such as official (or de facto) solutions for ORM, validation, sending (or receiving!) emails, authentication, writing custom utility commands, translations, i18n, background jobs, queues, admin dashboards, etc have a clear and either an official or de fact solution. That makes part of the "development experience" because developer experience is not just saving a script and seeing it refreshing in the browser. There's a lot more to it, like not having to reinvent the wheel at each step or tying together 10k third party libraries.
Remix, Next.js, blitz, whatever... those are all great solutions if all you have to build is a landing page with a form, or if you already have a proper backend in place, or if you have a team of several dozens/hundreds engineers and a ton of money to reinvent the wheel.
For solo or small teams or constrained budgets, nothing beats Rails or Laravel. There's a reason many of those frameworks wanna be called "Rails for JavaScript"... because none of them are anything close on their own name. Closest one is Adonis, and it's still a thousand miles behind regarding features, community, third party packages, being future proof and being battle proven.
They do have a lot of good advice, and I don't want to throw the baby with the bathwater. But they do get it wrong pretty often, and it does waste hundreds or thousands of hours having to go internally in an engineering org telling people "No, it's not because you read it on the internet that it's true".
A much older equivalent example was how back in the days in the Microsoft world everyone would say you HAD to use stored procedures for performance and security, ignoring prepared statements, so a lot of big companies had internal onboarding classes that always started with debunking it. Kent added a ton of confusion and did a lot of disservice to the unit testing space (the library is good, the philosophy lacks a lot of nuance), some other folks are creating a lot of chaos around SPAs/client vs SSR (they started adding nuance to that more recently), and so on and so forth.
It's part of why the JS ecosystem keeps restarting from scratch over and over instead of building on top and creating vertical innovation. We get there eventually, but it's so much slower than it needs to be.
The advice is, at this point, almost meme worthy. There's an infamous post from 2021 (that he may have been roasted for here):
https://kentcdodds.com/blog/how-i-built-a-modern-website-in-...
Almost every single piece of advice is wildly overcomplicated and ridiculous.
I do like some of the technologies proposed, but you can host this stuff on a single VM without any of the fancy frameworks, tools, or hosting options.
Kent is the only blogger that I've felt compelled to tell all my less experienced colleagues to completely ignore, and I feel entirely justified doing so whenever they bring him up.
The proliferation of his perspective has, quite literally, been a pain in my ass daily trying to re-teach misguided fundamentals. I really don't understand who the intended audience is. The expert beginner, maybe?
I'm sure he's probably a wonderful human being, however.