Hacker News Reader

It's not just him and is more of a general issue with frontend "thought leadership". Most of them went into it when they were relatively early in their career. There's no 1:1 relationship between years of experience and skill/knowledge of course, but if you pick any random FE influencer on Twitter, chances are they have less experience in the field than the staff engineer in your team. Unfortunately, it shows.

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.

His article is the epic antithesis of the KISS principle. Imagine being a beginner wanting to get into web app development and then finding out that the most "Epic Stack" requires you to learn 26 different pieces of technology, each with its own millions of nuances. SMH!

I agree.

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”.

I also agree. I thought it was a joke. Once I got to the logos I was sure it was a joke.

He was, indeed, fairly well roasted for it here: https://news.ycombinator.com/item?id=28818829

What advice is meme worthy? Can you be more specific?

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.

For one, Remix, actually. If you're "just trying to ship", the recommendation should probably be Rails, Django, or Next.js at this point. Flavour of the month technology is cool, but it's not mature enough to put in the "just ship it category."

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.

Tired of people calling Remix "flavor of the week". It's been acquired by Shopify, is actively being iterated on and is by no means another JS flavor of the week. I think it's proven itself in that sense so far.

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.

Exactly what one of the creators/marketers of remix would say, with a just crated account.

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.

Some people’s preferences are just what they’re paid to prefer. And some people follow their recommendations blindly. So it works.

I don't think he's straight up paid to recommend this stuff, just that as a blogger he thinks that he has pressure to blog about the latest hip things, which he probably does because he tends to blog about the latest hip things and that is what his audience expects of him. He's not a developer, he is a content creator for developers and that is a big difference, especially in a world where développées don't tend to move quickly ( or else we'd be rewriting our stacks every month to follow that flavor)

He works for Remix, last time I checked. So yes, he promotes things that are done by the people that pay him.

> He pitches niche, complicated stuff and tries to pass it off as basics.

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.

For those that are using open source js software to build web applications and are able to pick apart and understand what each tool does, his choice of tools are actually tried and true.

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).

> 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

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.

But the whole modern development it's a nightmare as I see, or at least the advertised modern serverless development, you need to depend on:

- 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.

The non-serverless version still works fine, even in modern JS land. The simple approach still works if you have some knowledge around setting up a server and configuring a few things.

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.

Even in the good old days you still had a database provider (often PHP plus MySQL in the classic LAMP stack) and in some cases an Auth provider (especially if you consider classic tools like Wordpress and Drupal as Auth providers). (Relatedly, the advice about Auth is best "don't roll your own auth" and that doesn't mean that you have to use an Auth provider, but at least use a library vetted by others. I also tend to add "don't keep passwords in your database" because that is a [legal/accounting] liability issue [more than being "hard", though it can seem hard to do right], which does make it good advice to find a third-party Auth provider you trust if you must support password-based workflows. Luckily some new options and libraries for password-less Auth are becoming slowly more common.)

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.)

"Serverless" is one of those names that kinda-sorta-almost makes sense: It's that your code runs "on no server (in particular)" rather than "on no server (at all)".

Someone stripped off that nuance in trying to come up with a concise buzzphrase for code that expects ephemeral access to an arbitrary server.

We can still do that. It still works. You can still just use rails or Laravel and deploy to heroku. Or just a single php file.

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.

I was convinced that he was going to sell this "Stack" for an exorbitant amount like some other Javascript influencers have done in the past. Thankfully this seems to be free at least.

I think you still have to be careful about folks selling training courses (or consulting services) to make sure that they aren't also glorifying complexity, even if they aren't trying to sell a product (or library or framework).

"You're wrong about the way you do unit test! Everything everyone is telling you is wrong! Fortunately, you can get my course that will clarify everything I just confused you about!!"

While I love testing-library, and have contributed to the sister libraries, one thing that always irked me is there was no empirical proof on why it was just better outside of handy wavy "because I said so."

Well, the more complex he makes things the more courses and consulting he’ll sell. It’s just marketing and his business model.

Why do yall suppose this for beginners? You can judge the tooling choice, but kek you ‘ll either pick the tools that’s given or make up ur own “stack”

Totally agree on this. If you look at him as a marketing person trying to sell you something instead of as a developer, it all makes sense.