Leaving Everything Behind For Elixir

[@_Aarius_]

Saying the ui should be disposable is not the same as saying you should dispose of you ui. Any and all real business logic should be server side. End of. The ui should only be a presentation layer. Deleting your entire ui and rebuilding it in a new framework with the same endpoints shouldn't risk breaking any real business logic.

[@iamnoone3588]

agree, fe and be should be separate from each other changing any shouldnt break the other which makes them “disposable” but being disposable doesnt mean you get rid of it totally

[@nowayicommented1314]

Thank you, I was a little sad that he didn’t get it and was only thinking of resources spent

[@gro967]

You need to visit the real world 😂

[@martoxdlol]

Use tRPC

[@nowayicommented1314]

@@gro967 you need to visit proper architecture

[@PavelPirogov]

My experience tells that backend should be frontend agnostic and reusable so different frontends could be implemented web/mobile/desktop and work with same backend. Good backend should be 100% usable with postman or curl.

[@AJewFR0]

why? this only makes sense when you need to use different tech for FE/BE. It’s like how microservices allow you to use whatever technology you need/want on different portions of your BE. Smaller teams do not need microservices. smaller teams do not need to divide FE/BE.

[@turculaurentiu91]

What if your project will never need a mobile app, or a tv app? What if your project is a website meant only for desktop browsers?

[@DanielCouper-vf5zh]

​@@turculaurentiu91that would be a case for colocating stuff as much as possible. I think people work in absolutes a bit much at times. That being said, an easy ability to test an entire application layer without the need to render anything is 👌. The tradeoff of needing to communicate with a separated UI is often worth it (particularly if the inverse is true of that layer, in that it can render without needing a backend during development)

[@tamal]

I couldn't agree more! But in real life, clients/Project owners spend more time with front-end/FS guys than a dedicated backend/DB guy. So I as a backend dev, ended up developing a BFF pattern to meet their demands. Each front-end (mobile, iPad, browser, core API, WS, etc) requirements are different. That's the reality.

[@n4bb12]

Unless the backend is all that needs to be built, it has a supportive role. A backend built in isolation from the frontend can only accidentally meet its needs and will hinder a good user experience.

[@proosee]

"Your front end should be 100% trashable and replaceable" - I always though that idea behind this statement is that those two layers should be separated, not that one part is more important than the other. Moreover, I agree that they should be separated, because server and client are fundamentally different.

[@ChristophFloat]

Came to the comments to say this. Theo seems to misunderstand that statement as some kind of diss towards FE development. I do not think that is what was meant. Clear separation of business logic and presentation has some pretty indisputable advantages, does it not? Like, you only have to write the business logic once and then can connect however many frontends you want to it (e.g. an SPA, an android app, an iOS app, native apps for Win, Mac, and Linux) in addition to providing API access to whatever it is you are building, if that is what you want. And they all can be beautiful and valuable. "Trashable" here does not mean "is trash". Also, BE code tends to be a lot more long-lived than FE code. If you build a nice FE now using bleeding edge technologies, chances are it will be outdated in a few years. Having BE and FE completely separate then lets you modernize your presentation without having to rewrite the entire business logic. But then again, I'm a BE dev, so I'm probably biased.

[@xbmarx]

I was a bit surprised by this as well. Where I work (media streaming company that's not Netflix), we have tons of clients: iOS, Android, web, even things like Roku, whatever the Tesla thing is, etc. Our backends don't care what type of client it is. It'd be an absolute nightmare if we mixed those two. We don't use GraphQL either, but we do have a pretty crazy API spec that gets statically validated with all the frontend clients.

[@proosee]

@@ChristophFloatnot only Theo, also the author of this article had the same impression judging by his following sentence.

[@styrofoamsoldier]

@@ChristophFloat Yeah I was very confused at this, I work in a company that has aspirations to make some functionality (ie. Business Logic with a capital B) shareable throughout our SaaS product range for easier integrations. If we bunch up a lot of business logic in the client (which we still have done, sometimes there's no good way around it) we lose a lot of that shareable logic. But put it in a shared library and a bunch of apis to services and you have pretty shareable business logic, that would in the best case scenario be very client agnostic, making the UI "trashable". That said, our UI is nowhere near uncoupled enough from the services it consumes to just be replaced easily. I wish it was, it's a horrid mess. This "trashability" question strikes me as an odd one, since there are so many different use cases for web technologies that there really isn't a mantra that covers them all.

[@phene-449]

@@ChristophFloat he only sees things one way, and that is the react way. notice how he seemingly takes every criticism as a personal attack. every time i watch a video of this guy i can't even make it through a full video. he's smug about it which is what i don't like.

[@lotfiholmes6397]

Dude, I'm not a ruby or rails dev but you reacted to the code all wrong and your bias was clearly showing and that was hard to watch, a few minutes in the docs and you could have easily understood that that code is easy to understand and modify to your liking.

[@secretythandle]

I think most people kind of miss the plot when it comes to Rails and it's conventions. It's not always the best convention, and the barrier of entry is a bit high, but the payoff is enormous just in the fact that you can take any Rails dev and put them on just about any other Rails project and they'll figure it out because they all have no choice (in most cases) but to adhere to conventions. JS projects I've worked on are the wild west, every project is radically different. Even two projects using the exact same technologies will be radically different because APIs get re-invented with no regard to backwards compatibility between major releases. THAT is JS fatigute.

[@srikanthav]

Wasn’t it 2014 when we had the (in)famous Javscript framework fatigue blog posts? It seems the cycle Sozin’s comet comes every 10 years in the JS land

[@rawallon]

JS inflation?

[@ninocraft1]

​@rawallon hot

[@0oShwavyo0]

Long ago the front end and back end lived together in harmony, but everything changed when the Node attacked…

[@Lemmy4555]

i'm glad that we had it though, thanks to the framework fatigue now JS is without any doubt the language where the community is really pushing the language forward with a ton of innovation: vite, svelte, solid, compilers vs runtimes, effects, deno, bun, typescript. No other language can claim to be effectively used in any context like JS.

[@0oShwavyo0]

@Lemmy4555 IMO that’s more a question of economics than any intrinsic quality of JS. The web is the most popular software platform, and JavaScript for decades was the only language that could be shipped to any browser without requiring the user to install a separate runtime (JRE, flash player, silver light, etc). Because everyone who wanted to interact with the web had to interact with JavaScript, it was only natural that with a large number of programmers working on the ecosystem, it would produce a large amount of innovation. JavaScript’s best quality is being inoffensive enough that folks deemed it worth making better rather than replacing it. If it had actually had to compete with other languages for its spot as the browser scripting language I don’t believe it would have won, but Netscape ruined us all.

[@m3ll0f3ll0]

I've never had more joy coding since learning elixir, seriously

[@frankyb702]

Not as fun as asp vbscript! Nothing beats asp!

[@foobarDEV]

you missed the concept of strong params where fields are filtered before handled by the controller. You might have written a ton of Rails in the past but i'm sure that was before Alan Turing was even born and it shows. FYI: if you really want to shit on any tool, language or framework just do your homework properly. Don't by blinded by your obvious hate for DHH. @t3dotgg

[@hectobit]

I find it hard to believe you actually wrote a lot of rails code. What you built in js was a JSON Api while the rails generated posts scaffold was a full CRUD UI, hence the edit & new actions.

[@ImperiumLibertas]

Jack of all traits, master of none. Theo has a lot of surface level experience with a lot of languages.

[@builtbywalsh]

@@ImperiumLibertas many people will regurgitate the idiom “jack of all trades is master of none” without realizing the quote in it’s entirety is: “a jack of all trades is a master of none, but oftentimes better than a master of one”. The original quote was a warning against this type of thinking

[@ImperiumLibertas]

@@builtbywalsh the original quote has nothing to do with the point I was making. Theo regularly proves that his technical knowledge outside of his silo is shallow yet he presents himself as very knowledgeable in many things. He's opinionated on things he has almost zero experience with. While being able to learn quickly is a great tool shallow knowledge is rarely beneficial.

[@EmblematicChalk100]

I'm not sure what's so confusing about Ruby example. The edit method is just an action for displaying edit form on the browser while update is actually the method that handles the actual database update when you hit submit. Same goes for create and new (new displays the UI create actually updates when you hit submit). It was a common MVC convention almost every web framework followed until the onslaught of SPAs. It can be confusing to someone who has never worked with a full stack framework like Rails, Laravel or Django just like how Next JS is confusing to people who have never worked with it.

[@pawebartulewicz8478]

Yeah, unfortunately Theo just did the same thing as the author of the article, but towards Ruby/Rails.

[@BorisBarroso]

Rails is has almost 2 decades and is still rocking I think the front end is not the best but you can use anything you want. The code that was presented is really simple if you understand the framework and the convention. Convention really helps when you work with a team and allows to understand better the code of other developers.

[@Greeem]

It's almost as if it's insanely confusing and convoluted if you don't know exactly what's going on behind the scenes. I can't read that code either. It's nonsense to me. Just because you understand how it works doesn't mean that it's at all apparent to other people.

[@thktomska]

​@@GreeemIsn't it confusting because you see only one layer of MVC framework? One gotta learn the whole cake layers before it'll be clear. So i'm not sure how fare this take is.

[@bra5081]

@@beowulf_of_wall_stOne should use the Rails convention, to understand what methods do

[@smurfssmur]

Damn Theo seemed pretty rude in this video lol

[@winchesterdev]

I've been using Elixir and Phoenix full time plus side projects for 7 years and I'm still in the honeymoon phase.

[@voltasi]

Me too 😂

[@tevoj]

Omg, this is my goal. I have started to learn Elixir/Phoenix/LiveView and soon will start to apply for some job offers.

[@JamesJosephFinn]

So, the job / work market demand for Elixir / Phoenix programmers is strong in your view? Context: I'm leaning learning Elixir as my first programming language, with a desired concentration in full-stack web dev. Thanks for any advice.

[@wojciechorzechowski2211]

I have switched from Python to Elixir and now work full-time in Elixir. I am finally happy at work and don't have to fight with the tech I use.

[@armynyus9123]

You had to fight with ...Python? I mean, yeah it's slow but fighting with it, that's not what Python is known for. Interesting.

[@ITSecNEO]

@@armynyus9123 This is just an ad for Elixir. No one uses Elixir for anything serious in production when Python is an option with way better frameworks too

[@rawallon]

@@armynyus9123 I think he's point is the same about Rails, you have to do things the Django way if you want it to work

[@pookiepats]

@@armynyus9123 try actually using it for work, what you’re saying is beyond false. It’s “known” to beginners because it’s marketed as simple to learn and while that’s true of the syntax it is not of the package & ecosystem - it’s literal hell if you’re devops. Python is dookie butt, definitely take time to establish your own opinions about things; what’s “known” is so far off base many times because the jokers that spread the knowledge ARENT IN INDUSTRY

[@ViniciusIth]

@@armynyus9123 Python dependency system and typing is just sad. I really had to fight with it a lot.

[@kokoinmars]

The "edit" action in rails gives you a page with a form where all the resource values are filled in, and then you can change those and push the changes back to the server, using the "update" action. I'm not exactly sure but the reason rails does it this way is to enforce CSRF protection. The "edit" action not only gives you a form with the current values for the resource being edited, but also a hidden CSRF token that is sent back to the server on submit (for the update action). The same applies when creating a new entity with "new" followed by "create".

[@msharno]

So much ignorance from Theo in this video

[@almirpask]

Theo committed a lot of mistakes in this comparison

[@GermansEagle]

Theo you got a little emotional when he, correctly, pointed out: frontend should be disposable. It's not that the work is worthless. But the you should be able to seperate the entire frontend from the backend logic.

[@ImperiumLibertas]

He was emotional the majority of the video.

[@Khari99]

I literally was just talking about making the switch from Next to Phoenix and migrating a lot of my personal projects to Elixir. I've been learning Elixir in my spare time for months but I only fell in love with it once I started using it. I feel like it rewrote my brain with how I think about writing code now and I just don't really want to go back to other languages unless its necessary. There's a Rustler package that allows me to use Rust when there is something thats performance critical. Phoenix looks a lot cooler than other JS frameworks because how Liveview is designed. The only thing thats missing is all of the tooling you can easily find with JS/React packages but I can honestly live without that for what the language features give me. I write a lot less code with Elixir and Im a lot more productive in it than I thought I would be.

[@hoshhsiao]

I went from Elixir to Node, and didn’t realize how much I don’t like Node until I started really using it. It’s the nature of the current job… but my personal stuff will still be Elixir.

[@Vladythebest96]

The whole criticism from Theo towards the writer are so toxic at times it’s shocking me. It’s almost like Theo is incapable of juggling in his mind that someone else might have a different experience of reality than him. If a developer’s experience led him to make particular choices which you as a critic disagree with, attacking him personally for his views is…well…rotten.

[@ImperiumLibertas]

Theo is attacking the author of this article who he doesn't even know personally because of his subjective experiences. It's more like Theo is trying to win an argument by dismissing the author's points because of his "lack of experience" rather than on the merits. It's like he lost respect for the author because he disagreed with him and therefore it's okay to attack him personally.

[@jamesperry4470]

Ya.. 5 YOE is not fresh out of boot camp and the guy has a network engineering degree. I can see where I disagree with the article too, but all Theo needs to do is disagree and provide evidence.

[@nazar_matus]

Dude, you tried to re-create a Rails controller logic in a DB abstraction layer. That is already done by Rails' model, which, when autogenerated, looks like this: ``` class Article < ApplicationRecord end ``` The `new` and `edit` controller actions are dedicated for rendering the "New Article" and "Edit Artricle" pages accordingly. That controller logic also handles form validation and re-rendering the form when failed to save, and redirection on successful save. And it also handles article deletion. What you wrote in your article.ts should be compared with the code block above, and that Article class already inherits much more boilerplate code that you're writing there. You are trying to be quick for your stream, and you miss the point.

[@Karg537]

I don’t think he is rails developer as he claimed.

[@nazar_matus]

@@Karg537to be fair I only remember him telling he did a lot of Ruby (not Rails), clearly he is not familiar with the most basic Rails MVC that hasn't changed for years.

[@avwie132]

But he did a _TON_ of Ruby 'in his time'. Note, this guy is 2 years more senior than the author of the article.

[@jamonh]

Regarding Rails codegen, experienced Rails devs quickly stop using `rails g scaffold` and instead generate single items with things like `rails g model` or `rails g view`. Then they immediately go edit those items. Scaffolding is really only useful for learning Rails or spinning up a quick demo app for something.

[@EightNineOne]

I've been using rails in earnest for under a week (Previously laravel) and I've used scaffold like twice to remind myself of some convention or something, then thrown them out. 100% with you on this

[@laztheripper]

Decoupling the front and back end has many benefits, for one. As long as my backend responds appropriately to requests from users, the specific language or framework used on the backend doesn't matter. Which lets me use faster technologies, or lean heavily into SSE and websockets where most full stack frameworks either limit or simply don't accommodate for such cases. Having components fetch data means the components can't work in anything that isn't built using the same API's and framework that matches the component's. It also means smaller components are harder to build without duplicating data fetches (creating additional server costs, and a general wastefulness that permeates most of "modern" web dev). If I leverage URL params correctly, all of the data required to render a page should be fetch-able at once (as opposed to per component), and assigned to state for the highest performance possible. Theo's main and only argument against this decoupling is "needing a whole complicated layer like graphql" to mediate interactions between client and server, or at the very least, provide a consistent api on both ends. But this is not a point against decoupling itself, it's more of a question about what technology we want to include in our projects that provides type safety and 1:1 contracts between the client and server. All of this is completely doable without graphql, and to say the only solution is to tie business logic to front-end UI, is wrong at least as far as I'm concerned. As an aside, just because Next is more popular, doesn't mean it's better. There was a time where react was a niche thing nobody used outside of facebook, but smart people saw potential and made it as popular as it is now, and it solved a lot of problems for a lot of people. As a general rule, I usually just do what is the most efficient, even if it's not the most popular way people are doing things, and it so far has paid off, because the efficient way almost always wins popular opinion in the end, by simple fact of being the better option. Anyway, I enjoy the vids, but I feel like theo is lost in react brain fog. There are other options, and unfortunately for react, it's being outclassed by faster and simpler (more opinionated) frameworks.

[@nextgaming4666]

Can you tell some replacement for react

[@ea_naseer]

​@@nextgaming4666this question feels like those questions in exams back in uni where they say mention and you think they mean list but they want you to list and explain... that's the vibe I'm getting here

[@laztheripper]

As lame as it sounds, I have to say *it depends*. If you're working on an existing project with a team and you're already a well-oiled machine, then stick to what works even if that's react. If you have lots of experience with react but are looking to build something completely new, then SolidJS might be a more natural transition for you, and if you don't have a requirement for SEO, then try just Solid as front end and pick whichever backend you prefer. This is one of the main pitfalls, you do not need SSR if you have no plans for search engines to index your site (SEO). Personally, I've been quite happy with sveltejs (both alone and sveltekit). One of my projects is a full SPA with an auth wall in front, and it's been handling my entire business with everything happening live (over websockets) and a lot of heavy work done by the client instead of the server. Because of this, my tiny 10$ a month vps could most likely handle 100k+ concurrent users without issue. My backend is nginx as reverse proxy + node + redis + postgres. There's also htmx, which has a place, but I have issues with some claims that are made about it. And I feel that lead to many people overhyping it (especially on youtube). All of that said, none of this is a magic bullet that solves everything, and it takes a bit more work and consideration. @ming4666

[@giuliopimenoff]

@@laztheripper really liked what you said, thanks for sharing. I do the same as you for small projects with a small vps nginx etc... (mostly kotlin on the backend), can you really handle 100k users on a $10 one tho?

[@giuliopimenoff]

@@laztheripper also yeah I would like to see from Theo a video where he does more than just db operations in the server routes (or whatever they call them), and does some more complex stuff, like you said websocket events for example

[@ernstvermeulen9126]

Rails' new and edit controller methods are used to display the views for creating and updating things respectively. The create and update methods are the ones responsible for actually doing those actions - usually triggered by something like a form submit. Afaik this is a naming convention that many mvc frameworks more or less share for crud resources. Laravel uses create and edit for showing the views, and store and update for making the changes, as an example. Surprised you did not pick up on this. That said, I've tried rails myself and also landed on the implicit magic being not for me.

[@camotubi]

I was about to type this. Liked the comment to bump it

[@0oShwavyo0]

What do you mean by “implicit magic”? I’ve been working in Rails for years, I don’t really run into much not covered by the docs and API reference. All of rails feels very “discoverable” to me, I can’t really think of any features that you can’t examine or interact with at a fairly low level.

[@0oShwavyo0]

Can you give me an example of this indirection? All I see are ruby methods and classes that I can interact with just like any other

[@0oShwavyo0]

@pcap8810 your inability to give a concrete example is pretty telling. Sounds to me like you’ve never read the Rails docs or looked at the source of any of the core libraries. Is there metaprogramming involved? Yes. Does that make it impossible to read, or mean that there isn’t tooling for making editors and users aware of those dynamically defined methods? No, we have plenty of tooling and you can also, idk, read the ActiveRecord source if you’re confused… There is no magic though, it’s all plain old ruby. Ruby has monkey patching, Ruby encourages meta programming. That’s not a rails thing, it’s just how people write ruby. You’ll find as many DSLs outside of rails as you will using rails.

[@ernstvermeulen9126]

@vyo0 To be fair - I must admit to having limited rails experience, but what I meant with 'implicit magic' is pretty much just what theo had pointed out. An example I can point to is a controller method magically being bound to a view with the same name, and so not needing to explicitly state to return the view inside the method. I know that's how it works because I read up on this in the docs, but I couldn't tell that immediately by looking at the code alone, which is a double edged sword. I also remember not being very impressed by the rails docs. Not dissing ruby though btw, I love ruby

[@RavinduNanayakkara]

Completely dismissing C# and immediately gushing over Rails scaffolding a basic CRUD API is comedy 😂

[@ScottMaday]

He didn't even bother explaining himself and immediately jumped into more obscure technologies because that's what his Twitter feed dictates he should do.

[@Beastintheomlet]

C# is a sleeper language to the web dev twitter verse.

[@Karg537]

In recent months I found there are more openings for c#, java and kotlin than other tech. Whatever it is, it seems like tech companies eventually found the traditional languages to be more reliable. OR fintech companies are the majority hiring at the moment.

[@joshdegraw3086]

C# is an amazing experience these days, highly recommend

[@lawnmaw4953]

C# is a mess of a language. If you add to it its enterprisey (java-like) culture and the fact that it is made by microsoft makes it the worst combination ever.

[@MrQwertyXoid]

Theo hyped StyleX, calling it the tw killer. The second i saw that stylex is ccsinjs, i noped out the hype train immediately. Now he's saying stuff like 14:03 "css in js was a mistake in so many ways". So are you excited for stylex or not? Is cssinjs actually the devil?

[@spikezkid022]

Liar, he never said that lol. Why are you lying?

[@MrQwertyXoid]

@@spikezkid022 kzbin.info/www/bejne/rGWrnJ6gjdJ4g68

[@talhaakram]

Bad take. The article had its issues (which can be dismissed as the author can be considered an enthusiastic youngster) but Theo really dropped the ball on this one. He made the same mistakes towards Rails as the author of the article did with JS frameworks. Also rant while comparing rails to next was in bad faith.

[@KieranHolroyd]

I see a lot of people saying this developer doesn't know what he's doing, I disagree. He understands very well what he's doing and wants to achieve, I personally feel that with this developer, he doesn't understand why he's doing these things, never stopping to ask why these things have been done, and why new things may be better. This feels like someone who is looking for perfection, and is completely unsatisfied with anything outside of that, when in reality most of a developers time is spent not chasing perfection, but making things work, and work well enough.

[@sheriffderek]

That's the real story here.

[@paxcoder]

I found you to be patronizing in this video. Unless you can tell and demonstrate exactly what the man's got wrong, you're not going to convince anyone.

[@imkir4n]

Surely this guy spend more time in twitter than writing code.

[@maximus1172]

Tech influencer bro, I just come here to pass time not to learn about programming, like watching a movie or something

[@spicybaguette7706]

I think he meant the guy who wrote the article lol @@maximus1172

[@HeartstringsMusic-j8h]

This is a common issue with so-called tech influencers who know very little about coding or the concepts behind it. The problem isn't as significant for experienced developers, but it's particularly problematic for juniors who are eager to improve. They follow channels like these and end up completely lost. The hype is relentless, with something new and supposedly better being promoted every day.

[@ITSecNEO]

@@HeartstringsMusic-j8h True, people like this also contribute to the language flame wars where every Junior dev sees a need to defend the language they use. Just out of fear that they choosed a wrong language or whatever.

[@markcollins3856]

Increasingly making thumbnails that make him look like they're pooing too

[@macccu]

Some hot takes and ammm, I think Theo is not really honest here. Especially when dunking on Rails and we all know how DHH typescript drama went. I mean if you spent 5 minutes with Rails docs you know what up with new and create for example. Which takes you waaaaaay further than 5 minutes in docs of any JS framework.

[@jawngee]

"I don't like codegen" *uses prisma*

[@fdg-rt2rk]

Lol moment. None of these clowns should be taken seriously TBH.

[@n4bb12]

He is using drizzle. No codegen.

[@jawngee]

@@n4bb12 his t3 stacks includes prisma

[@n4bb12]

Theo's point was that the code generated by Rails is not clearly distinguishable from hand-written code and mixes with it which makes purpose and intent unclear. Prima and similar tools output separate files that are never hand-edited and therefore do not fall in this category.

[@mestoris]

"I don't like codegen" *uses Copilot*

[@nikensss]

I agree with the article when it says "Your frontend should be 100% trashable and replacable", but in a way. As in, we should never get attached to any piece of code. Doesn't matter how many hours you put in, if it doesn't work, fix it, and if fixing it means throwing it away and writing it from scratch, go ahead. And that applies to both frontend and backend. I start seeing webdev in a more wholistic way. There are two sides (frontend and backend), but they become two sides of the same coin. And when delivering experiences to users, both parts matter. You can have the most incredible and scalable backend ever, but if the UI sucks, nobody will want to use it. And the same goes for the UI: you can have the most extensible, flexible, repsonsive, smooth UI, but if the backend is crap, the experience will suck. So yeah, in that case, one of the sides of this coin should be completely thrown away and rebuilt to match the quality of the other side, or rebuilt to provide a nice experience. I really don't get this whole FE vs BE wars, both parts are essential.

[@Karg537]

Frontend is disposable because the feature / ui failed to get expected outcome. The experiment has failed. The design system however should not be trashable.

[@HeartstringsMusic-j8h]

I think you haven't written much Ruby code. There's simply nothing that can come close to Rails in terms of scalability, maintenance, developer experience, or any other aspect. Having worked extensively on large-scale products built with Rails, I can confidently say that everything about it is smooth, elegant, and clean. Rails excels in providing a robust framework that not only scales effortlessly but also simplifies the development process significantly. Its convention-over-configuration approach ensures that developers can focus on building features rather than spending time on tedious configuration tasks. The extensive ecosystem of gems and plugins further enhances productivity, allowing developers to leverage existing solutions and rapidly prototype ideas. Moreover, Rails' emphasis on best practices and community support ensures that maintaining and evolving Rails applications remains a seamless experience. From its powerful ORM to its built-in testing framework, Rails offers a cohesive and enjoyable development experience unmatched by any other framework.

[@shllg]

I fully agree on your statement @mijokristo. I've been working on Ruby on Rails projects since Rails 2 (~2008/2009) and ever since with most of the JS techs and frameworks out there. From my perspective, the pure stability in the sense of APIs, conventions, backwards compatibility and project operations is not comparable to any JS (and other) frameworks out there. While @t3dotgg is arguing with missing experience and deeper knowledge of the different JS techs on Daniels side, he seems to have the same trouble when it comes to evaluate Ruby on Rails. We built many frontends (and a few backends) with JS: Stimulus, Hotwire, React, Vue, Angular but also Backbone/jQuery back then. While the JS world brought a lot of exiting concepts, new solutions and fresh ideas frequently - and is still doing so - many projects need to be rewritten or heavily refactored after a quite short period of time. And at the end, we're solving similar problems again and again. I'm not complaining about it. It is how frontends work nowadays. But just to put this in contrast: I recently took over, updated and upgraded an old Rails 4 application of an NGO with the last commit from 2017. It's running now on Rails 6 heading to we're heading to Rails 7 with it. This application has been running for years without maintenance (which is not good of course - but a different topic). Although it is not a super complicated and big application with a bit more than 20 db tables, the migration has been incredible easy and fast. Now the project can benefit from newer features but still the majority of all the previously written code is still in place. Many parts can be done better now and we can extend features based on the latest APIs. But it just works. Conventions, project structure, access to database etc. - all concepts stayed the same. I can even put a junior Rails developer on that 7 years old project. I'm not saying that it is necessarily good to keep everything like it is. But Rails still solves the problems in similar ways like it did in the past. The conventions turned out to be working very well throughout time - something you cannot say about the JS world. You launch a project incredible fast due to conventions (and if you want scaffolds). But also, you can add any kind of individual implementation in case you need this. Last word regarding the scaffolds: Those generate incredible good examples to start with. Especially for beginners. The majority of Rails developers I know don't use this feature at all. So it might not be a real world example for larger projects. @t3dotgg - What I just want to say: I agree with most of your points. But I think you are wrong with your opinion on Rails.

[@HeartstringsMusic-j8h]

@@shllg Totally agree with you. My journey with Rails began with version 3, and with each passing year, my affection for Rails has only deepened. I've smoothly upgraded dozens of old Rails projects, finding them stable, easy to manage, and consistently exceeding the expectations of customers and clients.

[@HeartstringsMusic-j8h]

@@shllg Totally agree with you. My journey with Rails began with version 3, and with each passing year, my affection for Rails has only deepened. I've smoothly upgraded dozens of old Rails projects, finding them stable, easy to manage, and consistently exceeding the expectations of customers and clients.

[@dtkedtyjrtyj]

I don't think it is an issue with how much Ruby he has written, rather that the Ruby(-on-Rails) way fits with some minds and not with others. It sounds like it works for you and you've had the good fortune to work on a code base this is maintained and everyone does it the Rails way. It just doesn't work with my mind, Just now I found out that there was a change to how `where.not` works. Granted, it was from completely insane to how you would expect it to work, but...

[@HeartstringsMusic-j8h]

@@dtkedtyjrtyj Rails approach aligns well with some developers more than others. My positive Rails experiences come from projects that fully adopt its conventions, simplifying development and maintenance. It shows the value of a cohesive approach in software

[@kieransweeden]

At around 17:48, you made the claim that Adam doesn’t write a lot of React code. At the exact point of making that claim, we can see in the description of the video that (at the time of the video’s release) he had been using React for 8 years. To write off people’s experiences with technologies despite them clearly putting in the time is close-minded.

[@trapfethen]

The frontend being 100% trashable is the norm when you're talking B2B applications as the UI isn't the primary means of ingestion, the API is. The UI is just a convenient way to adjust configuration and do some one-off tasks like download the audit report. A consumer-first application that is primarily ingested via the UI is where Theo is getting hung up, and that comes from his Twitch days. In those situations, it makes sense for development to be lead by the frontend team, as that UI will be your competitive advantage. The part of the post that should have been a dead giveaway for the distinction is when the poster said "The competitive advantage is the business logic".

[@ducodarling]

The front-end should be 100% disposable. You're stuck in your feelings. Encapsulations are always good. It doesn't mean the code itself is worthless. Being able to hotswap a front-end sounds pretty interesting actually. And just think of all the open source devs that worked to comply with some standard so that we can easily interchange libs (PSR-3, LLM, POSIX)

[@landsman737]

Honestly, it's a mess. We treated the frontend much better during the days of PHP applications than we do today. The unlimited possibilities to place everything anywhere lead directly to chaos. The fact that Next.js requires me to make two HTTP requests (one for the layout and one for the page) just to render simple meta tags hurts me mentally. Then they fix something like this with HTTP request deduplication by modified fetch ... it is bad magic that teaches people bad practices. PHP global variables again. If the Next.js framework introduced a simplified form of MVC that developers were required to follow (with warnings, build errors, etc.), it would greatly benefit the JavaScript development community, especially junior developers.

[@davidsiewert8649]

TLDR: Theo - the irresponsible Tech-Influencer

[@fdg-rt2rk]

😂

[@LubomirHerko]

22:00 I use ruby on rails for more than a decade now. I used scaffolding only handful of times once I was starting out with rails. Not even doing it while prototyping. As you said when you were commenting some nextjs feature - since it's there, noone is forcing to use it. You can create files with right click as weel with rails.

[@xbmarx]

Same. I'm not a Rails dev but I've worked with it several times because adjacent teams use it. I've never seen a seasoned Rails dev use the code gen or scaffolding

[@msharno]

This is the worst video I’ve seen from Theo. So much disrespect, ignorance and assumptions about the writer.

[@foobars3816]

So no different to all the other videos then?

[@frederick293]

Why not make a video for us who are new to web dev explaining the history of why different JS frameworks were popular at certain times so we can understand better and have more context?

[@ericng8807]

ngl its probsbly a bit less interesting than you might think. Alot of it had to do with big companies backing it and what your opinions of the companies were. I remember Angular1 being popular without any particularly good reason besides being made by google. Than at some point google pissed off alot of devs when Angular2 forced people to use TS. i personally knew some devs who bet on React because of that change. Altho now its probably driven more by how large the community is or specific features that older frameworks might not have

[@jagadishk]

probably because his career is less than 10yrs old.. he entered the workforce when things had started getting really good for FE.

[@1wisestein]

I wrote rails back in 2014-2015. I agree about your points on avoiding scaffolding for the same points you made however I’m confused about how you’re confused about what the generator spat out. I haven’t written this stuff in 8 years but that controller is very clear and isn’t trying to do too much. A surprisingly good starting point for someone building a blog or doing CRUD work. The controller just connects actions to views with models required to render them. It stays out of business logic and it certainly doesn’t concern itself with database calls. That’s why they say you want “fat models and skinny controllers”.

[@masterflitzer]

the article is right about this tho: frontend should be 100% disposable and replacable, if it's not you have a big mess where you cannot just write a new frontend, frontend changes so fast that a rewrite once every 5 years is realistic and if everything is mixed together that's just bad, doesn't matter we're in 2024, it's a bad practice nonetheless

[@merlin9702]

If you did not change the backend, then the usage requirements didn't change, which means you won't need to change the frontend. Take youtube for example, when they switched from star ratings to up and downvotes they would also have needed to change the backend. But if you're only changing the look of things then the js functionality doesn't need to change, just the markup and styling.

[@mugiseyebrows]

Theo defends javascript mafia by accusing backend mafia.

[@prophetjamz94]

27:26 I think here there is some context missing, the code shown in the original article was from the controller, and the instance variable (the cariable with the '@') is what will be passed to the template rendered when 'show' executes. What you replaced it with in `article.ts` is basically what's already abstracted in the data layer from ActiveRecord in the model class 'Articel'. To summarize your `getPostById` would have already been created in rails and is the same as rewriting `Article.find(params[:id])` which is already defined in the data layer. This is not say you are off but there is a lot of missing context in your deconstruction, but you are correct that it's not "obvious" and rails has EXTREMELY explicit and clear documentation.

[@electricshmoo]

It's easy to "sound like you know" what you're doing. These were not complex projects, so he doesn't get to really experience a large project's headaches. 2019 was yesterday.

[@0oShwavyo0]

@DanielBergholz you low key walked right into that one when you asked Prime/Theo to react to your article where the first line claims you have only 5 years of experience. Apparently that might as well be 0 years of experience in today’s developer economy (I’m around the same timeline so I’m salty too). I thought it was a pretty good article, but I think this industry is somewhat hostile to folks being too opinionated too early.

[@ViniciusIth]

@@beowulf_of_wall_st One role of yours lasting for more than 5 years honestly doesn't mean that much. And sincerely speaking, it feels like you guys are just attacking the Daniel for no reason. He can show his opinion as someone who has experience in a lot of different techs, without being attacked as if he didn't know anything about the web or how the Js bros brought us to this state of chaos.

[@dr_regularlove]

I feel like a lot of the arguments in the blog post are being dismissed too easily here simply because the author is a relatively junior dev, and due to some unproven but repeated assumption about their social media habits. I've been in this longer than you have Theo, scant little of my opinion on software design comes from social media, and yet many of the arguments you quickly dismissed rang as very true to me. I think you also took it as a personal jab against front-end dev when the author (and this could have been worded better) seemed to be making an argument for a boundary line between presentation and business logic. You dismissed this as having "separation of concerns brain" and then defended your position by showing a blog post on Next.js security which argued for (wait for it) one way to do separation of concerns (a "data layer"). In general, I just think you gave this a pretty ungenerous read, possibly because you are always at the ready to defend front-end dev practices which are, admittedly, sometimes unfairly maligned.

[@dr_regularlove]

Man you spend a lot of time expressing confusion over Rails conventions in the generated controller that have been well-trodden and unchanged since pre-1.0. Kind of weakens your many appeal-to-authority arguments about your relative experience. I personally haven't been on a Rails project in several years (finally started getting Elixir work after following its development since the beginning), but I remember those conventions just fine. "Wait till you have to debug this", sure, it's easy, it's a bog standard CRUD controller which implements a RESTful resource, an abstraction which is useful and applicable in any web service, Rails or not. As I write this comment, you've moved on to reading the rest of the blog post, and idk man, you're just very condescending, and I can't say I could recommend your channel for any new dev looking for fair advice from an experienced dev. I had to look this up, and, wait a sec, your first dev job was only 4 years earlier than the blog author's? That's where all this condescension is coming from, a difference of 4 entire years?

[@dr_regularlove]

I guess it's unfair for me to point out that you only have 4 more years experience than the blog author whom you repeatedly call out for being inexperienced or a "boot camp dev", because it looks like my comment has been deleted.

[@Karg537]

Most mvc apps are written like rails too. So I don’t understand his beef.

[@TheKennyWorld]

A story of a guy that just follows the hype and doesn't know what he's doing

[@ITSecNEO]

Couldnt agree more, this tech influencers follow every hype. Its just annoying.

[@sakithb]

He has a startup and worked at twitch, he definitely know what he is doing

[@ITSecNEO]

@@sakithb 1. Everyone can make a startup 2. "Worked" at Twitch, so obviously he is no longer there and I bet for a good reason xD Very weak arguments

[@paulrdrs]

@@ITSecNEOthe “guy” is the author of the article. Not Theo. It seems like you didn't watch the video.

[@ViniciusIth]

​@@paulrdrs But sincerely speaking, Theo did the same thing as the guy in the article. He criticized the guy a lot for following trends and then brought the strangest defenses for next/react as if because they were popular they were just better. Then he simply started using terms like "we stopped using this for a reason" as if every single developer stopped using some tech years ago and those who didn't were wrong. He said time and time again that the other guy "didn't have enough historical context" as if someone needed to be programming since 1993 to understand why somethings are better or worse for what they're doing, but the guy also had used technologies that derived from lots of different ideas and tested which worked better for him. And then he criticized the idea of decoupling the front and backend, and tried to prove his point by making a poll where people could say no twice and still had almost 30% saying that it should. He simply ignored it and treated as if the author was saying that someones jobs was useless, when he really didn't.

[@kauzinside]

On the codegen chapter (22:32), won't you consider shadcn style of builder a codegen? I recently jumped on a new codebase without the original team around, it took me some time to understand that their "ui library" was in fact generated.

[@killerwife]

I love the fact that I am using C# for my API, I can read your next react, and you are basically doing the same thing I am doing, at mostly the same speed. (coding wise, performance is a diff discussion) However I still hate everyone discounting modern C# and instead opting for something as utterly different as ruby. And elixir, would love to try it, but currently the job market where I am does not exist.

[@naughtiousmaximus7853]

Only Twitter takes a dump on C#. Java and C# are used in any serious company.

[@roguealien666]

As a developer that started working with flash and action script 2 and then changed to as3 and then flash getting banned from iPhone cause “Steve Jobs hated flash” I did learned that whatever you do if you’re going to be an early adopter, don’t immediately try and do everything with that new tech. Wait for that tech to mature and yeah do experiments and exercises with those but don’t do it. I almost did that with Deno thinking it would immediately replace nodejs and oh boy I was wrong, now bun seems like it will overtake but it’s an easier transition using it as a package manager only and then maybe moving out to it

[@rmschindler144]

“learning to say ‘no’ is an important skill as a developer” - hear, hear! . here, Theo is talking about saying ‘yes’ to a bunch of inclusions in the project that leave you at length feeling burnt out

[@unterdemasphalt]

Agree with everything you said, but the code in your article.ts file at 30:16 basically implements the ActiveRecord methods like `all` and `find` and that's only the database side of what the Rails controller actually does and can grow into. It's a full blown MVC Controller, not just a bunch of query functions. The generator doesn't seem ideal, but you're not really generating dead code. A lot of it is initial configuration.

[@phene-449]

you don't have to be smug any time someone offers criticism towards something that you like. you can disagree without being smug. i can't even make it through a video without cringing the entire time.

[@Frexuz]

"Oh hotwire.. Sigh".. Dude, it's so much better than htmx 😂

[@DevranUenal]

I really don't agree with you when you go through the rails controller. I have the feeling that you never used rails as a developer. How can you not know what /edit/:id does / how did you do it all the years while developing in rails? Having an option is great, but understanding something to provide valuable feedback is more helpful, don't you think? Background: It gets the `Article` data from the database, based on the id and returns a ruby instance of `Article` which is then provided to the view to populate the form fields based on the existing data, so the user can `edit` the values and submit an `update` to the server.

[@Greeem]

Every single one of these comments says the same thing: "I think you haven't used rails much" Yeah, obviously. Why else do you think he has no idea what the code is doing? It's because he hasn't used Rails much; or maybe it's because he hasn't dedicated a month of his life to reading every line of guides and API documentation for it. The fact that so many of you Rails devs need to come out of the woodwork to explain the code in that article is enough proof that Rails has way too much hidden nonsense going on behind the scenes. You don't need to be a savant with a framework to be able to look at some supposedly "basic" code and say "this is confusing."

[@DevranUenal]

​@@Greeem that's not the point. the point is that he claimed that he has experience with it at twitch. now he's telling that he has no idea what those methods do, is confusing to people who used it for a minute or two. and it gives to people who never touched rails a signal like "even people who use it have no idea.".

[@0oShwavyo0]

“Rails is good for people who don’t like thinking” Coming from the JS camp that approaches every problem with the attitude “well I was _already_ using JS for the front end, might as well use it to brew my morning coffee too” 🙄

[@simonhartley9158]

Separating FE and BE is all about tradeoffs. Do your tools still give you type safety? Are you introducing additional network trips to update the UI which could potentially be done purely on the client? Are you splitting your teams so that making a change requires back and forth in order to negotiate APIs? Do you have developers who are able to work on both?

[@capability-snob]

+ what interface is exposed to an attacker?

[@rhaikh]

28:30 rails dev here, your rant here is cringy to watch because you don't really understand the purpose of the Controller layer, or the conventions it is trying to support

[@mchisolm0]

I teach high school computer science and struggle to feel like I actually understand these technologies well. You say a bootcamp isn't the way to go; just go build stuff. I hear you. I feel like my time is too split and splintered trying to learn HTML, JavaScript/React/React Native, and Java (I teach CS 1, 2, 3, and 4) for me to build often and long enough to learn fully while also teaching daily. I feel like a bootcamp would be effective for me, and then I can use what I learn to give my students those skills. What am I missing?

[@timseguine2]

I like Erlang. Not enough to have extensively used it. But it has had a strong influence on my ideas about what a programming language should ideally be.

[@MrLordLowbob]

only ever used it in university for our distributed systems courses. I really liked erlang. having learned that language for roughly 4 weeks and then get tasks with multiple agents with hard real time requirements (

[@bugged1212]

Every video ever, oh this is great, this guy is great, great blog, but oh no I was almost liking it until someone pissed on Next.

[@nowayicommented1314]

Funny how attacked he feels when the guy says frontend should be disposable 😂

[@agmmdotdev]

i was thinking that xD

[@mattymerr701]

Your frontend and backend should obviously be loosely coupled. The interface should be well defined, but everything on either side of that interface should be replaceable without impacting the other side.

[@t3dotgg]

Why?

[@johanneswelsch]

Next.js and server components is the best thing that happened to frontend world since hooks came in 2018. You can now have large React apps have a light house score of 100 (mobile over 90). This wasn't possible before, because when you used any library in the past, the code for that would be sent to the client, but now can you build HTML with that package and ship just the HTML string with no extra javascript to the browser. You also don't need many dependencies these days. And the horror age of webpack configurations and custom create react app monstrosity is over.

[@dakdevs]

DHH and Theo pair programming session? 😅man that would be chaos

[@winchesterdev]

I need a way to set up an alert when someone streams Elixir content on Twitch

[@leonelvega7239]

Idk care I won't see an hour video but as far as I can say Rails is just a better tool period and that is it.

[@jon1867]

useLoader's typesafety is the same as RSC in practice. The remix docs / community doesn't typically suggest throwing `useLoaderData` anywhere but on the actual page, for that you would use `useMatches` in remix. I actually think the typesafety potential for remix's strategy is very very good. My thinking is if TanStack router can do it, remix can eventually do it as well because paradigm wise, they are very similar. I also wonder if eventually there will be something like Remix but for TanStack Router instead of React Router.

[@n4bb12]

From the post: "The competitive advantage you have against your competitors is the business logic". The competitive advantage is the value you provide to your users, including and not least the experience they have using your thing of which the user-facing parts are critical. The business logic is a servant to this, not the thing itself.

[@RetroGenetic]

I've had couple stints in web development since late 90's/early 2000's before I ended up in the field, I worked with PHP when I was in middle school (and made decent money), but that died down with many other things due to struggles with "being a gifted kid" pressure but no support and ADHD. Later I got back to PHP world, now with a bit of JS mixed around 2008-2010 but even then it was just means to make sure I get by. And as I got fed up with the field I was studying, I decided to hop back to development through the easy route (web dev) and so in March I bought course to update my knowledge and was hired in September, and yeah... That was a hot year, and yup I got in to React circle which I did like back then, now less so and I've become Svelte and HTMX enjoyer :D

[@Dipj01]

So did you get hired as a php dev this time?

[@RetroGenetic]

@@Dipj01 I did freelance work, and it paid fairly nicely.

[@aps69]

First of all nobody is forcing you to use the generators. You can only generate a certain part if you don't want the entire scaffold or just do it yourself. Second the index fetches the articles and stores them in @articles which can be directly accessed in the frontend. Same way show fetched one article. New initializes a article and renders a form and edit renders a form for your article. Also the params are not magic they come from url params and search params and you can control what params it permits and requires too. I've made almost same applications with nextjs and rails and rails took 1/10 the time and it is actually better. Now if you were to make something frontend heavy you might still want to add react or some other framework on top of rails but for most stuff, that isn't needed

[@akindurosegun2459]

The ruby code was objectively simpler… let’s be real here

[@Karg537]

The new function actually can be empty if the ui code is written differently: def new; end

[@seannewell397]

I like what you said about the lack of historical analysis to understand the _why_ behind each innovation / framework etc. Great thoughts.

[@stephendgreen1502]

Frontend replaceable? Of course. Every time you change part of it you eliminate what was there before. And customers constantly want it to be changed. So yes. Sad but true.

[@Karg537]

Same for backend code as well. Just that frontend code is more verbose.

[@stephendgreen1502]

@@Karg537 I guess I am influenced by so-called clean principles as taught by ‘Uncle Bob’ Martin and he tends to regard frontend and database as peripherals (like I/O in the driver world) and very changeable, but he teaches that the business logic should be less prone to frequent change.

[@brodacious1313]

It's disappointing to see highly upvoted comments putting this developer down. I think the article's tone of "this is the way" is ironic given his introduction to the article, but I tried to view it more as him explaining his journey to his current favorite stack. Are we really improving if we aren't looking back, embarrassed by our previous solutions now that we know better? Theo did a great job emphasizing this developer's potential, and their talent. Maybe they were a bit misled, as Theo stated, but having open conversations like these are what allow us to discuss what the current pain points and boons are with the technologies we're using.

[@LoneIgadzra]

Rails frontend is not the best, but if you're not using the whole thing I don't know why you would choose it for API. To be fair ActiveRecord lets you do a lot very quickly, even though it isn't type-safe, and has better migrations than most, but still. Rails partials absolutely suck, but they're easy to write, just not maintain. You KISS, and treat each partial like a region of the screen you want to update independently. Then you can do so with hotwire, very trivially. I like React too, but Rails is about mashing stuff together with not much code and getting a basically decent experience. Turbo frames let you be hilariously lazy. I like Stimulus very much, but it's for HATEOS - the exact opposite of React. Just adding a tidge of JavaScript here and there, not for major stuff.

[@story_of_us_]

As a developer living in Taiwan, Yeah, I want to use Phoenix as much as I can, but, THERE IS JUST NO JOB FOR ELIXIR DEV IN THE MARKET.

[@Karg537]

It needs a product company that is a caretaker of the framework just like rails.

[@codingtranquility]

I do agree with a lot of what he says in the blog post, especially about separating frontend from backend. And totally agree with not wanting to re-learn the same framework every few weeks ... it does seem like a lot of the changes made to versions are preference rather than improvement/innovation. I still feel like there's a better way, but I'm also not totally burnt out from React yet -- so we'll see once I reach that point.

[@dtm3dd]

“Trashable” was a poor choice of words, but “swappable” does seem valid. Being super locked into a framework for both front and backend seems objectively worse. I love Astro’s approach to this.

[@sivuyilemagutywa5286]

Samething, Trashable or Swappable.

[@dtm3dd]

@@sivuyilemagutywa5286 nah - Theo pointed out that it was implying the work was “trash”. Hence a poor choice of words.

[@bernatfortet5604]

not being able to use styled components because of SSR was the best. It allowed me to try tailwind, and I've never looked back.

[@yurii873]

is it market place? or actual vlog about coding ? ))) just curiosity )))

[@ankopainting]

The code gen comment put me off. Rails used to have way less code generated in the early days but they realised that showing a set of best practices on how you lay out your code was a useful teaching aide, and helps if you want a quick ui to do crud. But it doesn’t mean that you can’t just manually create a file. In practice it’s the best of both worlds.

[@HoNow222]

holy moly I can't stand theo anymore. am i too tired for tech influencers or what

[@nomadtrails]

Isomorphic js can be great. But I want Theo to stop trashing GraphQL. Even the Drizzle ORM team says you should use GraphQL instead in many scenarios... (Backend and frontend are on different teams, backend is not typescript, eg.... most scenarios beyond the smallest of scales). Add Hasura for auto-generating a complete schema for your db, and Graphql-codegen to get end to end type-safety between entirely disparate teams and languages.... Brother you got a production-ready stew going. At my shop we write most of our backends in Kotlin and most of our front-ends in Svelte Typescript, because that is what our engineers prefer, but we don't have to. We could pick any language/framework on either end of the stack and GraphQL would still be the glue that forces everyone onto the same page. Works great and scales. Just prioritize a sane database design and watch out for N+1 queries, which might not be as easy to spot when using GraphQL compared to raw SQL or Drizzle.

[@peepeepoo3432]

I would argue the current Next.js model is less "typesafe" than Remix loaders. I've been using Server Components in production for over a year and I'd argue that allowing the developer to call functions and "hope" for deduplication can easily introduce either over abstraction, server waterfalls or unnecessary queries or all of the above as soon as the app grows. Remix's model for loaders keeps data fetching in one place for the small price of having to pass a single generic to useLoaderData whenever you call it. So yeah it's not really more "typesafe", but Next is hiding stuff under the carpet to achieve that level of typesafety which I don't think is worth the compromise. I understand you can still hoist stuff to the route in Next too, but afaik there's no such thing as convenient as useLoaderData that can work for both RSCs and client components, so you have to prop drill the hell out of data which makes it even more annoying. With Remix's lack of RSCs (for now) the whole data fetching model remains simpler even at larger scale.

[@henriquematias1986]

/edit is like “getServerSideProps” for the /edit page. “/update” is the endpoint that the /edit page frontend will Post to. It does make sense ( : It’s like /edit is a page and /update is an “api endpoint”. IMHO talking smack about cake, RoR, jungle or any of those frameworks who paved the way for Next and other modern frameworks makes no sense in 2024, if it wasn’t for them FullStack JS would be very far from where it is right now. Back in the day over 15 years ago when brilliant people invented it was gold, really visionary and they take little to no credit for it in today’s scene. In the other hand a lot of JS devs who had it easy now think they’re entitled to criticise their acestors

[@mathiasfischler4227]

Love the outer wilds sticker on the laptop - got that same image with a little extra art on a t-shirt and my girlfriend has that exact sticker on her water bottle. Hope you enjoyed the game as much as I did Theo :)!

[@gaiusjcaesar09]

Design should be disposable. UI should be flexible. 'business logic' should be dealt with on the backend, accessible through API's. I work for a very large energy company, they change design every 2-3 yrs, hence, we have a team that works on that and creates UI library we use. The components shouldn't break by upgrading the UI library.

[@taylor.w.merritt]

I agree with not having type safety being an issue with Ruby on Rails, but I think it’s a disingenuous argument to call out RoR as being non-understandable code when you seemingly aren’t familiar with building full page apps with RoR (making the assumption that your RoR experience was using it as an API backend, could be wrong though). Also, in the stream I think you mentioned that the JS library fatigue was more of a non-issue these days, but you then (in the stream) proceeded to take 10-30 minutes fumbling around with picking the correct libraries to use with create t3 app. The t3 app is from you and your team in addition to you being familiar with all of these technologies and it still took that long for you to get started and choose the libraries. Now put yourself into the shoes of somebody getting into JS dev and I hope you could see that library fatigue is still a real thing, you’re just way more familiar with all of the libraries so it’s more of a non-issue for yourself. Overall I appreciate the content still though, I just mainly took issue with this portion of the video because it seemed like your bias was really showing and preventing you from seeing the author’s perspective.

[@dahermora5976]

Let's be simple: That was an amazing review. Thanks, Theo.

[@hipertracker]

Separating the frontend layer from the backend provides a lot of flexibility, especially when both layers are complex, and particularly the frontend. For example, it allowed me to switch the backend from Ruby to Python. As for GraphQL, you need to familiarize yourself with Hasura, it's effortless. Hasura connects to PostgreSQL and automatically creates a very powerful and flexible GraphQL endpoint.

[@cherubin7th]

37:20 Such a beautiful opinion. I fully agree.

[@angry_moose94]

you sound like you're a "meh" person

[@cherubin7th]

@@angry_moose94 Such an ad hominem meh comment.

[@angry_moose94]

@@cherubin7thoh no way!! surely you weren’t able to spot that the comment was ad-hominem even after the OP (you), deleted the comment it was referring to??

[@mauserzje]

what did twitch use before react ?

[@prophetjamz94]

As a Ruby/Rails Dev, I'd like to point out that RUBY is readable, not so much Rails. And after my first year of dev work I stopped using scaffolding and rails generate pretty much all together for new features unless it's to generate a migration (less headache that way). And naturally as a ruby dev I have nothing but good things to say about Elixir. I recommend giving it, and Phoenix a try for web and try some of the other tooling in the Elixir ecosystem as well like Nerves

[@mestoris]

Being a long-time Rails dev, I find I dislike different things than Theo. I don't like how implicit rendering works. I don't like how routing and params work. I don't like how database connections are managed globally. In short, I don't like magic. I too dislike generators, but leaning on gen AI has the same drawbacks.

[@t3dotgg]

This is one of the most measured disagreements I've had in my replies in awhile "I find I dislike different things than Theo" - this was great, stealing this format in the future 🙏

[@deepakpatidar8462]

At this point, whatever gets your product out quickly with decent performance is a good framework.. I think optimising an app comes when your have a large number of people using your app and you need to scale.

[@kokoinmars]

Elixir may not have paid courses, but it has some of the best textbooks every written for any programming language. I haven't been able to find any JS books, and books for Java, C++ just put me to sleep. Ruby has some decent texts, but it all pales when compared to Elixir/Erlang books

[@zolongOne]

C++ primer plus by Stephen Prata is a good c++ book.

[@OliverQuixchan-gu7ip]

to visually include the OP info card just to give credit to their content would be amazing in these review article type videos. At the end of the day, good or bad takes, their content can give some insights. We're all learning together. Great theo takes tho, I agree 95%

[@henriquebarros8303]

Maybe Rails overview wasn't fair once that you proprable, through you reactions, didn't tried follow the 15 minutes guide. In the video, you are trying to build a kind of "JSON API" instead of using the 100% server-side Rails toolkit. It's more than make a CRUD at server-side. The 'new" and "edit" are functions not just to make a http request, they are used to create instance variables to forms, to create a page, to broadcast events using Turbo Links (By the way, you don't need to create a "re-render" function or a write a line of JavaScript code when you're using Turbo Links. Everything can be handled from from templates that can be reused anytime.) Yes, we know it's not a silver bullet, or the best thing created. But neither is JavaScript and is still used as it. We're bringing habits from other languages into our development in tools like Rails, and trying to use patterns we learned elsewhere, having a less happy experience.

[@cg219]

Have you tried o again since?? I got back into it and its such a better experience now from when I originally tried (2019ish)

[@RodrigoMallmann1]

I am about to implement RTK and RTK query on a nextjs using Pages. It's so much better to be sure about stuff than to figure out as we go. App router might be production ready but I am not production ready for it

[@t3dotgg]

This is totally reasonable

[@snippyboons]

Been working in Elixir for 4 years now. I'm not a fan of it because it doesn't have the same language features as a functional language, but also lacks a ton of features from C-like languages. Also the ecosystem is all centered around Phoenix and Ecto. It's also a dynamically typed language that lets you shoot yourself in the foot with pattern matching. You have to write so many test cases to not do that. Credo is ok but most of the time the errors are ass. I'm very excited to switch back to a statically typed language. Dynamic languages were never meant for the backend.

[@madlep]

Literally just got back from a meetup after giving a talk on Go vs Elixir (at a Go meetup), and Theo opens with “I just couldn’t enjoy Go after working in Elixir”. I can relate 😑