This kinda reminds of that guy that wrote the post criticizing Tailwind CSS because he couldn't use it to write the really advanced transitions and animations that he needed to. He wasn't wrong that Tailwind was insufficient for his use case, but he also clearly wasn't the target audience for that tool. Rails definitely does not provide the same level of granular UI polish that React does. But if you can get by without needing that granularity, you can absolutely fly with a very small team in way that you just can't if you're going full stack JS. An experienced Rails dev is going to absolutely cook an experienced JS dev on delivery time given the same set of functional requirements, and that matters in the post-ZIRP era.
💯 with you! Those privileged devs that have never developed an app from.start to finish - and then made 10 apps like that - till they finally found a product /market fit. I don't care how many requests it makes. I have 4 weeks. And I need to build 10 apps till I ran out of money!
As someone who's dabbled in both worlds, it's absolutely shocking to see js devs spend hours to an entire day dealing with react, typescipt or tooling bugs. Not to mention re-building everything in 1-2 years all over again because some new shiny standard has come out. It boggles my mind even more that people use js to build startups.
I don't wanna get into the framework wars because they're pointless. But can we all agree that a network request on each keypress is ridiculous. No matter your tech stack, its just horrible design.
I might hack this for an internal company tool that serves ~100 folks concurrently. Or as a POC to see if people like it as a product, and to test if there's a market for this product. But, yeah, at Hey's scale, it's a little boggling that they did this.
@@shikharraje That's the thing though. If concurrency is a feature of your product then it makes sense, look at Google Sheets, Notion etc. Making a guess here, but even they would batch these requests at the least so it reduces the overall load. But when we're talking about an isolated form field that no one except for you is going to see, it doesn't need to be persisted, it resets between sessions or even component mounts - there's no excuse to do this.
I’m a hobby rails dev and enjoy building stuff with rails. I absolutely hate it when these tech/dev influences crap on the thing I enjoy using. It’s really demotivating. The more I see Theo, the more I think he’s bad for the dev community. He may have some valid points, but a lot of his arguments are absolutely garbage and are there to make himself feel superior at the same time as generating baiting content. I hope people manage to see through Theo’s bullshit. We need more people like Aaron Francis in the community and less people like Theo.
I'm surprised this is how people see Rails (It seems like a 10 year old impression of what rails was). I'm primarily a rails engineer and I see it as a flexible framework that allows you to use whatever your preferred front end technologies are. You can make your client only need to set a request header to request a full page load of html, an html partial, json, or whatever your requirements are. You can have the same end point capable of responding to someone accessing the end point directly/full reload, through an internal website link, or through your native app simply by defining an html and json view.
People see Rails this way because dev content creators like Theo care more about click bait content, than they do about being a positive force in the dev community. I hope Theo looks back on this content with embarrassment some day soon and changes his ways, but I'm not holding out.
I'm definitely more on the "classic side" of web development, but the obsession with 0 JS is dumb. These conversations are basically never about trying to get the best of both worlds, instead it feels like this HEY app is trying to be a point more than the best product, which sucks.
The problem is Hey isn't even zero JS. Zero JS is where your static blog doesn't need a JS interpreter to be readable. Sourcehut is usable with zero JS: the interactivity is limited to forms and links, but it presents a pretty efficient workflow for its use case. Seeing Hey and other apps that need a pretty sizable client side chunk of JS talk about how they are zero JS is just... ridiculous. If it doesn't work in Lynx or EWW due to the lack of a JS interpreter then it's not "zero JS".
@@kisaragi-hiu "zero JS" in a Rails context doesn't mean that apps send 0 JS over the wire, the idea is that developers don't need to write much, if any, of their own JS. Turbo is written in JS and therefore needs to be loaded in the browser, but it eliminates the need to write much custom JS, similar to HTMX. And Hey loads about 25% as much JS as TH-cam, it's a fairly reasonable amount by modern standards.
my apps use fairly little JS only to start webassembly stuff Why becuase IMO JS should be used sparingly, only when necessary JS isnt for logic JS is for dom manipulation
What you did in this video was just hitting a straw man, you took a website that has a poorly optimized UI and you are using it to define the entire Rails ecosystem. Understand, this site may be poorly optimized, but it is not Rails that did this. It is completely possible to improve the UX of this website. I'm not a Rails fanboy, but this was completely unnecessary. I know Theo has a beef with DHH, but it was unnecessary
The point is that without some JS you can’t optimize the UI further and Rails creator are so insisted on no Javascript is the way. Maybe ecosystem think differently and that’s ok.
@@chakritlikitkhajorn8730that's badly informed. DHH just say most people don't need these heavyweight JS frameworks. All their products use Stimulus, a lightweight JS framework to not touch the server on small updates.
didn't he say that at the start? he even acknowledged that the next js official example is also ass too, so the hey app may also just be an ass example. i think his bigger gripe was DHHs response and the perception of what people think a fast internet connection is.
The funniest thing about this drama is that rails people don't realize that there's a huge part of the world where slow internet is the default. I would pull my hair out if I had to see a spinner after every action
I lived in germany for a while (being from chile, where good internet is the norm), and man I noticed how stuff worked differently, with differently I mean like hey
You are fully right, but there are a couple of well known software architects stating, that those regions should simply be ignored, since these are not of relevance for IT business. That kind of view on the world is part of the issue.
@@MiguelMartinez-ui8nl Then you must have been living somewhere remote. I live in Germany too and my internet is incredibly fast. I just tried out Hey and it has almost no lag for me, but yeah; if you went to the countryside, then I'd completely understand why you had slow internet. If you live in a somewhat rich area of a big city, then you'll see 5G ethernet cables everywhere. I mean, I'm connected to one right now! It just mainly depends on the Bundesland ("federal state") you're in and if you're in a big city or somewhere at a farm ;) But that's just my experience... Yeah, internet here isn't the fastest compared to Chile. It's very fast in some places, but at some other places you have to even try to get signal. I agree that our politicians need to do more to get faster internet speed, especially considering they wasted around 220 million euros on a quite simple Coronavirus app. This money would've helped A LOT to expand our 5G and even 4G network.
The Rails community was in prime position to be “running” the developer experience (like the JS community is now) back in 2014ish to 2018ish (Iike they had been up from 2012ish to 2014ish), but they fumbled the bag big time, and that is 100% on DHH. All he had to do was keep providing educational content for new developers and integrate React and Typescript into Rails. Instead, DHH purposely avoided SPAs and offered no out of the box support until much later on. The new devs in that era needed some creators to learn coding from, but all there was, was Rails Cast and that was outdated for the newer versions of Rails and what wasn’t out dated was never explained to still be good. They essentially made it impossible for new developers to learn the Rails way and opted on focusing only on their existing audience from their early days. That worked fine until the next developer group came along. That is why you see so many JS related educational content now. They will not make the same mistakes Rails did, and we know what it’s like to struggle to find good (and entertaining) educational material like JS community has. New devs can make it in the JS world still even though Next JS is kind of pushing it. It’s at least not so magical that you feel like an idiot using it because you don’t know what it’s actually doing behind the scenes.
I see the point, and it's absolutely valid on a technical level. But in practice as a Hey user, it's never been an issue for me, on desktop or mobile even from abroad in a third-world country. Occasionally there's something that doesn't pop immediately, but it barely registered until now. It probably helps that I'm happy with the service itself, probably the best experience is somewhere in the middle between full reloads and JS (since going full JS has the problem of syncing state with the server)
I completely agree with your argument. but what is the point of testing latency with a VPN connected to France? 12:18 "okay, let's see what this is like to use in the EU then." your test here does not test what it is like to use the app in France, it tests what it is like to use the app with latency of multiple roundtrips, from SF to France to SF. I can understand the point of testing high latency though (high latency only, bandwidth uncapped, the Australia test).
@@sames44048 I'm not saying testing high latency with a VPN in general is pointless, testing how your web app works with high latency is a good thing to test. I just said the test where he connected to a VPN server in France does not test what he said it tests: what it's like to use that web app if you are in France. (essentially, because he's not in France, or more accurately, the machine he's doing the test on is not in France)
@@sames44048 it actually is because Theo read the tweet that they are in the process of _finalizing_ the new Europe DC and assumed that means it's _already_ done and decided to test the Europe latency based on that. You see how he misunderstood what he read, right?
@@yawaramin4771 No, that is unrelated to what I said, I'm saying assume the EU data center was already there and operational, the test Theo did at 12:18 does not test what he said it tests (how the site is like to use if you're in France, because he's not in France, or more accurately, the machine running the test is not in France) You can't just connect to a VPN to another country to test what the site is like to use there, it doesn't work, because there's latency between your VPN's server in that country and your machine. and I'm not saying that testing high latency with a VPN is pointless in general, it is a worthwhile thing to test your web app with high latency. so the high latency test he did earlier in the video is fine.
I feel like a bit of this is pulling at strands. I'm no Ruby user though the content shifting that lasts for a blink feels like such a nitpick for something I feel only enthusiasts focus on.
100% agreed. I’m a regular user of Hey (so, bias out in the open) and have never noticed any of this. Because it truly doesn’t matter for the consumer experience. Build shit for customers, not for other devs to think it’s cool.
Chrome and firefox both have tools built in to simulate latency. The problem is the assumption that both latency and throughput are a constant. Spikes can give a much worse experience that will easily be noticable to users, but developers will rarely notice.
It's truly astonishing that some people think the benefits of having a local data center can simply be replicated by using a VPN in the same region. This demonstrates a fundamental misunderstanding of how data infrastructures work.
I'm afraid people are going to take the wrong lesson from DHH's antics here. HTML over the wire can still be good. 0 JS is stupid as you still need JS for interactivity, but maybe you don't need a SPA-framework on top of all that. Edit: ok, I'll admit, "antics" was a bad word
DHH has never done 'antics' like saying 0 JS, you could easily see this for yourself just by opening up the HEY app and looking at the developer panel to see the JS. Or it would have been even easier if Theo had shown it in his video instead of pretending it doesn't exist. Or if you literally now go and look at DHH's tweet showing the few lines of JS they added to their frontend code to fix this issue.
It's not DHH's 'antics' that are the issue here. It's Theo's antics. He has potential to be a really positive force in the developer world, but he really likes to shit on others instead of pointing out issues in a positive way and helping people fix/avoid them.
You admit 'antics' is a bad work but not that you were blatantly wrong about 0 js being used here? You sound like the kind of dev that pick tools based on hype, without digging into it and seeing what is best for your customers/users/employer. A lot of places I've worked at are quick to boot out individuals like you who are seen as a costly liability.
Submitting a form multiple times has nothing to do with js vs html. You can do that in react too UNLESS YOU MAKE IT NOT DO THAT, which you can with any other over-the-wire framework too, wether its turbo or htmx
I have a feeling DHH is building a one man show with Rails like you can build everything with Rails but stuff like React or Angular can only do stuff well on the FE with the same amount of labor. Recently I have to do Ruby at work and I finish so many things in comparison with React. I would admit that React is faster than Rails but with Rails you can ship faster but not as good
The issue with Javascript frameworks is most of them impose crazy structural changes that force you to rewrite the codebase to upgrade. Migrating a large application from Vue 2 to 3 is a nightmare.
Reminder that DHH being a problematic d-bag doesn't necessarily mean Rails is dumb, or that it doesn't allow you to do things the way you want -- whatever that happens to be.
@@vnshngpnt I don't know, I've seen many users complaint about hey, if you try to talk to the people that hey has a testimonies, in their own website have stopped using it and that was years ago.
Email and calendar are a offline first apps by definition. I want to be able to create an event in my calendar while there's no internet on a section on the train, and it should sync automatically. I need to be able to mark email as unread while on an airplane, and it should sync automatically. The fact that this dhh guy is claiming the opposite, is borderline scary
this is why i use thunderbird. i generally hate installing desktop app if web app exist but email is exception. i need my email and calendar to be accessible anywhere anytime.
@@RoflMcCopterthe browser gives you a local storage tho. It is essentially an local app. The best sites can be even loaded entirely from cache without needing internet at all. Your writing essentially plugins for the vrowser its not that deep.
The hilarious part is TH-cam (the site you posted this video to) takes the rails approach in many cases, including for mobile apps! Apparently, it’s fast enough for the largest video platform in the world, but go ahead, tell us more about why we NEED client side JavaScript.
That's because Google can front the bill for insane amounts of requests. Click the "Save to Playlist" button and notice how a request is sent for EVERY checkbox click. The obvious thing to do would be to send ONE request when the user closes the modal, but I guess basic state management is too much client side behavior.
@@benbowers3613Traffic and bandwidth is extremely cheap or in some cases, entirely free! Vercel builds a "modern" UI around these cheap and free services and up-charges you insane amounts. My $5/month VPS has 35TB of free bandwidth, and I pay $1.37 per excess TB. Similar speeds to when I used Vercel, but with a monthly bill with less 0's :)
Also, funny how he is nitpicking on a single functionality that is glitchy. YOU CAN DO THE SAME WITH REACT!!! Specially on components you render that need a network request to render the final version. Has this guy built anything that he can call a business other than a TH-cam channel???? We have gone from creators to "B.S content creators".
do you work for vercel? To me, A. The complaint about how every keypress goes to the server says literally nothing about HTML over the wire. It’s obviously how Hey chose to do things (or it was a bug), but Theo should be experienced enough to know that most approaches don’t need to be like this. Attributing a sloppy implementation by Hey onto a video about Rails as a whole is inflammatory. B. And if he isn’t, and doesn’t realize that HTML over the wire doesn’t mean you can’t have any JavaScript, he should stop talking about what he does not understand. C. This is personal taste, but a man with his hair style shows he can’t recognize good taste if it hit him in the face.
@@TheVimeoI'm sure Vercel is very happy with him with the amount of teenagers he brings in that don't know how much Vercel up-charges the services they resell under a different UI 😅
@@liyatini is this is js universe is fucking sad. the dude is like trump. yells and cry, lies, lies, and big ego. everyone is shit, look how cool and smart I'm has a nice moustache at least :) PS: his cool startup, if you do on network, just expose to private channel, that is funny :))
Linear with the same throttle takes 2 - 3 minutes to show anything at all. Now what do you think the regular user will mind more? That depends for everyone, but I definitely would prefer the site where it just takes a little longer for a modal opposed to one where I have to stare at a void for 2-3 minutes.
My best guess is that there's some real-time validation going on (scanning for prohibited words and possible injection/attack vectors? but why would you do so real-time if there's no feedback to the customer anyway?) and since they proudly boast no client-side JS they have to send the text to the server for validation.
I am a Laravel developer, i used all there is, Inertia, full separation API + SPA, Livewire, Hotwire( is framework agnostic), HTMX. All i can say is that Laravel + Inertia or SPA gives you full controll over everything, you want something except static (by default, you can get there but it is not a default), you want SSR, React SSR or React SPA? All these 3 you can get with Laravel and Inertia, all 3 at the same time, you don't have to choose one! What I see unfair is saying that HTMX crosses the bridge more then Hotwire or Livewire. All 3 of these are all the same, Hotwire and HTMX are framework agnostic and Livewire is for Laravel only, all 3 allows you the same amount of stuff and have the same amount of limitations, the big difference is the DX, Livewire + Laravel is way better then any other approach, both for developing and testing, but as a drawback, it limits you to the Laravel framework.
What i am trying to say about HTMX is that, if Hey was written in HTMX not Hotwire and they wanted that pop-up to still be rendered on the server, it would have been exactly the same experience. Same with Livewire. The only thing different was how you write when and what get's rendered there. The biggest problem with Hey is that their app renders 20 lines of HTML is over 300ms, and that is just bad, and i come from PHP, for me having more than 50ms in the same region to render HTML (Authorization being counted in) is just horrible.
Hey @t3dotgg and @ThePrimeTimeagen! Could you please do a video about HTMX vs Hotwired+Stimulus+Turbo? What you recommend Inertia over it? What are other solutions if you render html on server and if you don't want it to be written in javascript?
This is an insane thing to say. That's 2 seconds of time to the system to respond to stuff. As someone in a remote area with a bad internet connection (~600ms ping), I would find HEY to be infuriating to use. I'm sure other actual users that live with bad internet connections would, too.
On the other hand, I can't stand UIs that pretend something has happened before the server request has actually happened. Show a spinner or something but don't just pretend it's happened (i.e. don't move the HEY event until it's processed on the server or show it moved but greyed out or with a spinner _and_ move it back if it fails). It's completely confusing and leads to potential data loss etc..
Your VPN isn't really a fair test since the data has to be sent to the location and then all the way back to you, so the latency is essentially doubled. I agree that I would never choose to build an web app the way they have either and I also find DHH posts to be annoying, but I am a paying customer for Hey because I still enjoy the user experience more than Gmail. The latency isn't bad where I live and if I ever travel, since I just use Hey as a Gmail client, I can just log in to my email on Gmail instead. That being said, the only time I've ever felt the need to do that was on a Starlink internet connection in the middle of nowhere.
Uploadthing has a lot of the same quirks with user interaction with no pending state allowing for multiple submissions without knowing it. Most of these issues are less JS vs. Rails and more attention to detail misses. We all do it, ship fast and forget. This is not blaming anyone it’s more just saying we live in a world where there is no restrictions to what can be posted on the internet and therefore we also live in a world filled with jank 🤷
Latency is often way more significant than bandwidth. In the past I've sometimes had to bounce an SSH connection off a GEO satellite! So... f-ing...slow!
Hey theo the latest angular 17 and 18 revisions have been focusing more and more on server side rendering. I think you might need to do some explaining
What’s strikes as very strange to me is that Hotwire indeed provides all the building blocks to make the UX for Hey not suck (via stimulus), and yet the company that created it doesn’t seem to do it well. That being said, I currently write ruby/rails for a living and agree people default to relying on the server way too much.
@@SeanLazer It's not supposed to be a replacement for React/Angular so I'm not sure why you would even say it's not a good replacement. It's closer to jQuery than React.
@@jl789nz because 37signals doesn't use any frontend libs and don't provide any official bindings for using them a la laravel and inertia. Stimulus is "the rails way" for doing your client side code
I just learned that VPN breaks physics and that connecting to another country adds no latency because the latency between the VPN exit node and my browser is zero! they must use quantum entanglement to pull this off. 🤦
The point was to simulate a slower connection, like someone’s shitty LG phone, which is used by a significant number of people as their primary internet connection. Even if we go a step up for satellite internet (non Star Link), it would still feel slow. No one said anything about how VPNs work as that wasn’t the point, but I guess that flew right over your head.
I think in the end it's about a feeling that things are fast rather than making things faster when data needs to be saved on the server. The main difference in this comparison is how quickly the user gets a feedback that something is happening. This is vastly better in case of GCal as things seem to happen before they're done. GCal also has more animations that make the user feel that things are actually happening when you're actually waiting for data to be transferred.
Can someone explain why everything needs to be in a browser? A mail client is a perfect example of a native app that works way better than any web based solution ever could. The same goes for vscode and other example of heavy client side apps. If something is that client heavy why not simply develop it as a proper program/app?
@@chakritlikitkhajorn8730 I am not sure about that one. If it is easy to install many will just install an app. On phones that is very common, but due to the headaches program installations on windows are, many people don't think the same way for desktop apps. I would say that if it's easy to install most will prefer to just get the app for the best experience. If you are at the point where you install a browser extension to use a mail client site, you might as well download a full mail client. The only difference is that the extension will slow down your browser on every page load even if it is just a bit, in exchange for being easier to install.
I have some honest questions: 1 - If rails hates js why when you are creating a new rails app you have the option to setup the app natively with esbuild, bun, rollup or webpack? 2 - If rails hates js why the majority of projects i already worked on was rails with vuejs? 3 - why you used an example "laravel + intertia" when intertia has adapters for both laravel, rails? 4 - what is the sense of relating a product ux testing with a web framework? HAHAHAHAHAHAAHAHAH
I love your content Theo, but being a fellow Australian, I am offended by the way in which you said "Brisbane". I have never heard it said in such a strong American accent before haha
After watching some of your videos I'm starting to question just how knowledgeable you really are... This comes off more as a fan boy hater rant honestly. I've been building websites since the early 90s and I've been working on and off with Rails systems for two decades now, including fully responsive client heavy systems which got tens of billions of requests a month. Not sure how bashing Rails over what is clearly just bad site design is supposed to accomplish other than making you look ignorant. You can still have a shitty site even if you run everything in the client. Running everything in the client doesn't make it magically better. How magical is it when the client just "fakes" the updates and the server calls fail in the background? Or even worse things get magically undone after the server call fails. That's an even worse experience when it looks like you actions instantly happen only to revert seconds later. Heavy clients are not a magical fix and can suffer all the same issues in reverse. It all comes down to proper architecture, design and using the proper tooling and solutions to accomplish the goals set forth. Just because you can do something doesn't always mean you should. If the goal is to have a super responsive client heavy application then one should use the appropriate technologies to accomplish that. If you want to avoid being client heavy then one should again use the appropriate technologies to do that. Painting yourself into a corner with hubris and bias is the hallmark of a bad and ignorant engineer. It's always a balance; both approaches come with trade offs. Being client heavy gets you responsive apps in theory, but also a slew of browser compatibility issues; slow devices with limited memory also tend to run client heavy apps slowly. As mentioned if calls fail you can have things look like they updated only to have them undone on a refresh (or if the app is written properly seconds later). Server heavy apps, while slower, provide better resilience and integrity as you can be assured it won't update until the server is updated. It's always a trade off no matter the approach. One thing I can say for certain, based on metrics for client heavy systems I've worked on with global reach, the average consumer is on a shitty device which often tends to process those client heavy apps way slower than one would ever expect. Most people have cheap or old computers and phones with slow processors and limited memory. The most recent Rails system I worked on did surveys in major mobile games globally (think rewarding in game currency for answering questions) and was completely client heavy where Rails was just a JSON API backend effectively. The average response time for Rails was 40ms; the average render time in the JS client was 2-4 seconds. Sure for a bunch of tech bros in SF on gigabit connections running the client on the latest hardware with plenty of memory it's easy to make the argument you are making; but in the real world with hundreds of millions of consumers spread across the globe the answer is never that clear cut. To think otherwise is asinine. You seem to focus solely on the latency when in reality the client's hardware and memory has the biggest impact. If you perform the same client vs server tests on shitty/old client hardware the server will win every time. It's all subjective as fuck no matter what argument you want to make. There is no right or wrong way; you just have to strike a balance based on the lowest common denominator if you want a decent experience for everyone. Of course if your only consumers are people in SF on gigabit with modern hardware then client side is probably the right call; however if you have a business that reaches people across the globe on mobile devices you're not gonna have a good time with that. Your personal bias is on full display with this one. Try checking your ego and hubris at the door and stick to the technical merits because this just makes you look like a clown and hater who doesn't even understand the basics of technology or how to build sites and services. One thing I've learned after being in this business for three decades; there is never a right or only way to do anything - and anyone that says otherwise is either inexperienced, ignorant or a fan boy trying to sell you something.
Bashing rails without knowing rails lol. The tweets mentioning that Vue have easy pairings with React etc. Rails ALSO has that if you want :) Or just use the awesome Stimulus framework. It has nothing to do with Rails being anti-JS, because it's far from it, but the choices of how Hey was implemented.
5:57 - You raise a great point, many people don't consider the impacts on latency, and the sometimes surprising impact it can have when there's a lot of back and forth. There's even more metrics that go into an internet connection than just bandwidth and latency too. Loss is another metric which can impact in profound ways when compared to latency or bandwidth. For realtime applications you also have to consider jitter (change in latency over time).
I understand hating React, but hating JS so much that you want everything rendered on server is very limiting mindset. There is the reason why this kind of architecture is so dominant, it didnt appear out of thin air.
Not saying I agree with all the Hey decisions in the video, nor if it would be great to build this in React or Vue, but this constant shaming of technologies that people don't use nor even want to use is such a negative vibe in the tech-industry. Just keep using whatever technology makes you happy bro.
I have no quarrel with rich clients that provide a smooth experience to the user and enable clever offline. I do have a quarrel with doing it in an inadequate language such as JS/TS.
Don''t know theo but have watcned some videos of his. I am assuming I am missing something. How could someone with a technical background not udnerstand that when you use a vpn in another country you are connectin to a server there FROM THE US? so what in the world did testing for that do to show actual performance in the country?
the idea of needing to go to the server just to show a dropdown is absurd to me. even the dropdown content is static, there's nothing on that dropdown that needed data from the server, you could literally just include it in the html or js then toggle it on click
I don't really care about Rails and haven't even looked into it, but I find it really ironic that React devs are so horrified about this when this kind of awful performance and bugs can be witnessed in many React applications as well. :D
If the literal creator of React built a really bad React app, then claimed we were all wrong and dumb when shown how bad it was, I would be just as annoyed.
Literally every technology can be bad if implemented incorrectly, your logic can be applied to anything. It’s not if there aren’t a ton of poorly coded C++ applications, don’t get me started on some JAVA apps. I’m talking apps where the client is built with these languages, not the server side. I’m mostly talking desktop software or purely native apps (coded in JAVA/Swift coded, not React Native) mobile apps. No one wants to talk about how many bad client side desktop apps there are though, do they? Especially back in the day before the web really started taking over application development.
@@t3dotgg Yeah I get that. But still I can't help but feel that both parties are resorting to some degree of whataboutism and saying everything is way worse on the other side.
As a Rails dev I totally agree. Rails makes great APIs but I've always hated it's frontend. The "helpers" are confusing and frequently misused, the templates are simply worse than anything modern, and Ruby is comically slow. I also miss static types, it makes it hard sometimes but it's not the end of the world like some people say. If I'm using Rails I'd rather have a JS framework as a frontend, but Rails + React will never be better than Next
1:40 not sure what the fuss is about. It’s super easy to add progressive front end interactivity on server side rendered apps. No framework required. Though Vue.js does make client side interactivity super easy.
I think the best pipe analogy would be bandwidth is the pipe's thickness, while the pipe's length(instead of water speed) is your latency, as you don't really change the volume of data you can receive every second, but the distance the data has to travel to get to you is larger
I'm not saying this product provides a good user experience. But I think 100/1 people care about it. And I'm sure DHH has thought about that a lot. And as developers, yes, we should care about it. I don't know.
old gen: auxiliary -> terminal -> graphical -> hypertext -> im still learning. new gen: i know everything -> rich-internet application w/ graphical widgets and augmented multi-dimensional reality-*breaking*...
Did you not know desktop email clients exist? Writing emails on a plane was never an issue and pretending that everything has to be a web app is not just idiotic it is feeding this "you own nothing" rent seeking that has almost become the norm. These nickle and dime fees have gotten so bad there are services just for tracking all your subscriptions.
I've had to use a satellite internet connection with >500ms latency and only around 20-50kbps bandwidth for work. the number of modern websites that weren't just slow but straight up didn't was ridiculous.
The fact that you thought using a VPN to connect to Europe would somehow magically allow your packets to teleport over.... and when you're comparing against google as an example of one being better than the other... uh no they're both garbage ~ the fact that you were probably being served by some nice google server in Sydney (sub 200ms per request) versus god knows whatever server that was giving you 400-500ms responses is reason one seems better than the other. Have them swap servers and you'd thing it was google doing something wrong...
You can fix the frontend bugs. - Add a delay to the requests that are sent out as you type so that a request is made only when the typing has stopped. - Drop the event in the new position and if the request fails move the event back. - Preload the new event html and just display when the button is clicked to avoid. It's more skill issues and bad QA. I've seen bad code from JS frameworks, too. The framework doesn't fix the developer.
His request goes to the VPN Endpoint in australia, then to the google server in australia and from there back to the VPN Endpoint and only after that to him in SF.
@@AK-vx4dy If google only had server in SF, it would be like this: Theo (SF) -> VPN (Au) -> Google (SF) -> VPN (Au) -> Theo (SF) But, because Google has servers in Au, it's like: Theo (SF) -> VPN (Au) -> Google (Au) -> VPN (Au) -> Theo (SF) So you remove the latency from the VPN servers to Google servers, but the packets still need to travel to Au and back to Sf. This is still fair because you can simulate what happens in a normal case where a user from SF sends a request to an Au server
@@Hapkumdo I try to tell that Hey may not have servers In Australia so request to hey is going to Australia, back to US then back to Australia and then back to sf again
It's just about how Hotwire was implemented in Hey, Theo! There is no silver bullet on software development. SPA is not the greatest thing in the world. There are situations where SSR fits better than others approaching. Your channel is just for entertainment, but not to take it seriously. Sorry.
I don't think you can objectively test Google's infra against a VPN when they have "servers on the edge" of various worlds regions. sometimes you might get a session to be sticky to a server in a non optimized region, but doubt it'll last more than two requests to mount to a closer server
Where does the notion of Notion being "local first" come from? In my experience it doesn't work at all with no Internet connection. Neither the web version nor any of the apps. A much more deserving candidate to shit on tbh
7:12, just an fyi from an Aussie, 'Brisbane' is pronounced as briz-bin or briz-bən (or briz-b'n if you're especially Australian) and never as briz-bane
As someone who frequently has 300+ ping (but great bandwidth) to servers, it's often painfully obvious which sites are relying on the server being fast.
I'm not saying you're wrong on all accounts, but man.... it's a successful paid product - that's what matters first and foremost. It works. You're putting it to the test under weird constraints at time. Also, a lot of those you can fix if it truly matters for the UX. All in all, I find this a cheap stab at Rails.
This kinda reminds of that guy that wrote the post criticizing Tailwind CSS because he couldn't use it to write the really advanced transitions and animations that he needed to. He wasn't wrong that Tailwind was insufficient for his use case, but he also clearly wasn't the target audience for that tool.
Rails definitely does not provide the same level of granular UI polish that React does. But if you can get by without needing that granularity, you can absolutely fly with a very small team in way that you just can't if you're going full stack JS. An experienced Rails dev is going to absolutely cook an experienced JS dev on delivery time given the same set of functional requirements, and that matters in the post-ZIRP era.
this
💯 with you! Those privileged devs that have never developed an app from.start to finish - and then made 10 apps like that - till they finally found a product /market fit. I don't care how many requests it makes. I have 4 weeks. And I need to build 10 apps till I ran out of money!
I would rather have a less polished UI than gaping security hole leaking customer data.
As someone who's dabbled in both worlds, it's absolutely shocking to see js devs spend hours to an entire day dealing with react, typescipt or tooling bugs. Not to mention re-building everything in 1-2 years all over again because some new shiny standard has come out.
It boggles my mind even more that people use js to build startups.
I don't wanna get into the framework wars because they're pointless. But can we all agree that a network request on each keypress is ridiculous. No matter your tech stack, its just horrible design.
No doubt. Although it seems like more of a bug as opposed an intentional design decision.
I might hack this for an internal company tool that serves ~100 folks concurrently. Or as a POC to see if people like it as a product, and to test if there's a market for this product. But, yeah, at Hey's scale, it's a little boggling that they did this.
@@shikharraje That's the thing though. If concurrency is a feature of your product then it makes sense, look at Google Sheets, Notion etc. Making a guess here, but even they would batch these requests at the least so it reduces the overall load.
But when we're talking about an isolated form field that no one except for you is going to see, it doesn't need to be persisted, it resets between sessions or even component mounts - there's no excuse to do this.
It's ridiculous, but it's not about framework!
Yes, local first is based. Network first is trash.
I’m a hobby rails dev and enjoy building stuff with rails. I absolutely hate it when these tech/dev influences crap on the thing I enjoy using. It’s really demotivating. The more I see Theo, the more I think he’s bad for the dev community.
He may have some valid points, but a lot of his arguments are absolutely garbage and are there to make himself feel superior at the same time as generating baiting content. I hope people manage to see through Theo’s bullshit.
We need more people like Aaron Francis in the community and less people like Theo.
Very well said!
Totally agree! I'm so glad I'm not the only one who feels this way
I'm surprised this is how people see Rails (It seems like a 10 year old impression of what rails was). I'm primarily a rails engineer and I see it as a flexible framework that allows you to use whatever your preferred front end technologies are. You can make your client only need to set a request header to request a full page load of html, an html partial, json, or whatever your requirements are. You can have the same end point capable of responding to someone accessing the end point directly/full reload, through an internal website link, or through your native app simply by defining an html and json view.
People see Rails this way because dev content creators like Theo care more about click bait content, than they do about being a positive force in the dev community. I hope Theo looks back on this content with embarrassment some day soon and changes his ways, but I'm not holding out.
I'm definitely more on the "classic side" of web development, but the obsession with 0 JS is dumb. These conversations are basically never about trying to get the best of both worlds, instead it feels like this HEY app is trying to be a point more than the best product, which sucks.
The problem is Hey isn't even zero JS. Zero JS is where your static blog doesn't need a JS interpreter to be readable. Sourcehut is usable with zero JS: the interactivity is limited to forms and links, but it presents a pretty efficient workflow for its use case.
Seeing Hey and other apps that need a pretty sizable client side chunk of JS talk about how they are zero JS is just... ridiculous. If it doesn't work in Lynx or EWW due to the lack of a JS interpreter then it's not "zero JS".
0 JS is great on a website that that works for, such as my personal website which is a static HTML site.
@@kisaragi-hiu "zero JS" in a Rails context doesn't mean that apps send 0 JS over the wire, the idea is that developers don't need to write much, if any, of their own JS. Turbo is written in JS and therefore needs to be loaded in the browser, but it eliminates the need to write much custom JS, similar to HTMX. And Hey loads about 25% as much JS as TH-cam, it's a fairly reasonable amount by modern standards.
my apps use fairly little JS only to start webassembly stuff Why becuase IMO JS should be used sparingly, only when necessary JS isnt for logic JS is for dom manipulation
There is no 0 JS but MINIMAL JS.
What you did in this video was just hitting a straw man, you took a website that has a poorly optimized UI and you are using it to define the entire Rails ecosystem. Understand, this site may be poorly optimized, but it is not Rails that did this. It is completely possible to improve the UX of this website. I'm not a Rails fanboy, but this was completely unnecessary. I know Theo has a beef with DHH, but it was unnecessary
Can't believe I had to roll two pages of comments to get a sane one.
The point is that without some JS you can’t optimize the UI further and Rails creator are so insisted on no Javascript is the way. Maybe ecosystem think differently and that’s ok.
@@chakritlikitkhajorn8730that's badly informed. DHH just say most people don't need these heavyweight JS frameworks. All their products use Stimulus, a lightweight JS framework to not touch the server on small updates.
@@chakritlikitkhajorn8730 rails is not and has never been about no JS. People really need to stop listening to Theo.
didn't he say that at the start? he even acknowledged that the next js official example is also ass too, so the hey app may also just be an ass example. i think his bigger gripe was DHHs response and the perception of what people think a fast internet connection is.
The funniest thing about this drama is that rails people don't realize that there's a huge part of the world where slow internet is the default. I would pull my hair out if I had to see a spinner after every action
I lived in germany for a while (being from chile, where good internet is the norm), and man I noticed how stuff worked differently, with differently I mean like hey
You are fully right, but there are a couple of well known software architects stating, that those regions should simply be ignored, since these are not of relevance for IT business. That kind of view on the world is part of the issue.
@@MiguelMartinez-ui8nl Then you must have been living somewhere remote. I live in Germany too and my internet is incredibly fast. I just tried out Hey and it has almost no lag for me, but yeah; if you went to the countryside, then I'd completely understand why you had slow internet. If you live in a somewhat rich area of a big city, then you'll see 5G ethernet cables everywhere. I mean, I'm connected to one right now! It just mainly depends on the Bundesland ("federal state") you're in and if you're in a big city or somewhere at a farm ;)
But that's just my experience... Yeah, internet here isn't the fastest compared to Chile. It's very fast in some places, but at some other places you have to even try to get signal. I agree that our politicians need to do more to get faster internet speed, especially considering they wasted around 220 million euros on a quite simple Coronavirus app. This money would've helped A LOT to expand our 5G and even 4G network.
The Rails community was in prime position to be “running” the developer experience (like the JS community is now) back in 2014ish to 2018ish (Iike they had been up from 2012ish to 2014ish), but they fumbled the bag big time, and that is 100% on DHH. All he had to do was keep providing educational content for new developers and integrate React and Typescript into Rails. Instead, DHH purposely avoided SPAs and offered no out of the box support until much later on. The new devs in that era needed some creators to learn coding from, but all there was, was Rails Cast and that was outdated for the newer versions of Rails and what wasn’t out dated was never explained to still be good. They essentially made it impossible for new developers to learn the Rails way and opted on focusing only on their existing audience from their early days. That worked fine until the next developer group came along. That is why you see so many JS related educational content now. They will not make the same mistakes Rails did, and we know what it’s like to struggle to find good (and entertaining) educational material like JS community has. New devs can make it in the JS world still even though Next JS is kind of pushing it. It’s at least not so magical that you feel like an idiot using it because you don’t know what it’s actually doing behind the scenes.
I don't think it's fair to judge the people who's using Rails because of DHH
they are still shipping faster and making more money than js devs though.
Doesn't inertia work w ruby/rails the same way it works w php/laravel (and even django or w/e backend)?
Yes!
yes, but that one got me too HAHAHAHAHAHAHA
I see the point, and it's absolutely valid on a technical level. But in practice as a Hey user, it's never been an issue for me, on desktop or mobile even from abroad in a third-world country.
Occasionally there's something that doesn't pop immediately, but it barely registered until now.
It probably helps that I'm happy with the service itself, probably the best experience is somewhere in the middle between full reloads and JS (since going full JS has the problem of syncing state with the server)
I completely agree with your argument.
but what is the point of testing latency with a VPN connected to France?
12:18 "okay, let's see what this is like to use in the EU then."
your test here does not test what it is like to use the app in France, it tests what it is like to use the app with latency of multiple roundtrips, from SF to France to SF.
I can understand the point of testing high latency though (high latency only, bandwidth uncapped, the Australia test).
How else would you test latency? Or are you saying latency testing is pointless here?
@@sames44048 I'm not saying testing high latency with a VPN in general is pointless, testing how your web app works with high latency is a good thing to test.
I just said the test where he connected to a VPN server in France does not test what he said it tests: what it's like to use that web app if you are in France. (essentially, because he's not in France, or more accurately, the machine he's doing the test on is not in France)
@@sames44048 it actually is because Theo read the tweet that they are in the process of _finalizing_ the new Europe DC and assumed that means it's _already_ done and decided to test the Europe latency based on that. You see how he misunderstood what he read, right?
@@yawaramin4771 No, that is unrelated to what I said, I'm saying assume the EU data center was already there and operational, the test Theo did at 12:18 does not test what he said it tests (how the site is like to use if you're in France, because he's not in France, or more accurately, the machine running the test is not in France)
You can't just connect to a VPN to another country to test what the site is like to use there, it doesn't work, because there's latency between your VPN's server in that country and your machine.
and I'm not saying that testing high latency with a VPN is pointless in general, it is a worthwhile thing to test your web app with high latency. so the high latency test he did earlier in the video is fine.
@@wis9 I agree, the premise of the test was faulty on multiple parameters.
I feel like a bit of this is pulling at strands. I'm no Ruby user though the content shifting that lasts for a blink feels like such a nitpick for something I feel only enthusiasts focus on.
Users will percieve these just not articulate it. It will just feel "off".
100% agreed. I’m a regular user of Hey (so, bias out in the open) and have never noticed any of this. Because it truly doesn’t matter for the consumer experience.
Build shit for customers, not for other devs to think it’s cool.
@@klnmn3722 I'm not even really a dev and i think it looks awful. I wouldn't use that as a customer.
A bad work man is always gonna blame a tool.
Chrome and firefox both have tools built in to simulate latency.
The problem is the assumption that both latency and throughput are a constant. Spikes can give a much worse experience that will easily be noticable to users, but developers will rarely notice.
Always test drive your site using TOR, basically.
It's truly astonishing that some people think the benefits of having a local data center can simply be replicated by using a VPN in the same region. This demonstrates a fundamental misunderstanding of how data infrastructures work.
yeah he actually gave the worst possible show case that crazy I thought he would know a bit about networking
I'm afraid people are going to take the wrong lesson from DHH's antics here. HTML over the wire can still be good. 0 JS is stupid as you still need JS for interactivity, but maybe you don't need a SPA-framework on top of all that.
Edit: ok, I'll admit, "antics" was a bad word
Like for listing stuff with filters it works fine, but for high interactive page you should deal with JS
DHH has never done 'antics' like saying 0 JS, you could easily see this for yourself just by opening up the HEY app and looking at the developer panel to see the JS. Or it would have been even easier if Theo had shown it in his video instead of pretending it doesn't exist. Or if you literally now go and look at DHH's tweet showing the few lines of JS they added to their frontend code to fix this issue.
It's not DHH's 'antics' that are the issue here. It's Theo's antics. He has potential to be a really positive force in the developer world, but he really likes to shit on others instead of pointing out issues in a positive way and helping people fix/avoid them.
You admit 'antics' is a bad work but not that you were blatantly wrong about 0 js being used here? You sound like the kind of dev that pick tools based on hype, without digging into it and seeing what is best for your customers/users/employer. A lot of places I've worked at are quick to boot out individuals like you who are seen as a costly liability.
You can scale your backend by eating more red beans and rice.
Squats are important too.
😂
DHH living rent free in theos head
it's job security for frontend devs "we matter"
Submitting a form multiple times has nothing to do with js vs html. You can do that in react too UNLESS YOU MAKE IT NOT DO THAT, which you can with any other over-the-wire framework too, wether its turbo or htmx
But Theo, users don't care about great app interactivity.
They care about 3 letter domains and rounded modals with gradients.
And layouts with huge gaps and paddings and shadows. Material is literally the most disgusting design I have seen
I have a feeling DHH is building a one man show with Rails like you can build everything with Rails but stuff like React or Angular can only do stuff well on the FE with the same amount of labor. Recently I have to do Ruby at work and I finish so many things in comparison with React. I would admit that React is faster than Rails but with Rails you can ship faster but not as good
Ruby on rails is a really good way to build your first version of your saas app if you are into starting businesses.
@@xswordsIt goes beyond that. We dumped React and are now literally building twice as fast our competitors can’t keep up.
The goal of Rails is indeed to provide opportunity for single dev to do everything. So it’s a feature
The issue with Javascript frameworks is most of them impose crazy structural changes that force you to rewrite the codebase to upgrade. Migrating a large application from Vue 2 to 3 is a nightmare.
Reminder that DHH being a problematic d-bag doesn't necessarily mean Rails is dumb, or that it doesn't allow you to do things the way you want -- whatever that happens to be.
Are you sure it's not Theo that is being the problematic d-bag here?
DHH isn't the one being a problematic d-bag here. It's Theo.
Hulu, twitch, Airbnb and co are still super smooth with Rails….
Hey is also smooth, guy in video is just doing some weird tests that don’t represent actual UX
@@vnshngpnt I don't know, I've seen many users complaint about hey, if you try to talk to the people that hey has a testimonies, in their own website have stopped using it and that was years ago.
No ? Twitch moved out of Rails
Email and calendar are a offline first apps by definition.
I want to be able to create an event in my calendar while there's no internet on a section on the train, and it should sync automatically.
I need to be able to mark email as unread while on an airplane, and it should sync automatically.
The fact that this dhh guy is claiming the opposite, is borderline scary
They're offline first, but not necessarily for websites. As mobile apps, yes, since they can have a local DB.
this is why i use thunderbird. i generally hate installing desktop app if web app exist but email is exception. i need my email and calendar to be accessible anywhere anytime.
@RoflMcCopter with PWA features you can make a website offline available and use indexeddb for local storage.
@@RoflMcCopter websites can use things like local storage to store data on the browser like a database.
@@RoflMcCopterthe browser gives you a local storage tho. It is essentially an local app.
The best sites can be even loaded entirely from cache without needing internet at all.
Your writing essentially plugins for the vrowser its not that deep.
The hilarious part is TH-cam (the site you posted this video to) takes the rails approach in many cases, including for mobile apps! Apparently, it’s fast enough for the largest video platform in the world, but go ahead, tell us more about why we NEED client side JavaScript.
That's because Google can front the bill for insane amounts of requests. Click the "Save to Playlist" button and notice how a request is sent for EVERY checkbox click. The obvious thing to do would be to send ONE request when the user closes the modal, but I guess basic state management is too much client side behavior.
TH-cam is primarily a content consumption app and not a productivity app.
@@benbowers3613Traffic and bandwidth is extremely cheap or in some cases, entirely free! Vercel builds a "modern" UI around these cheap and free services and up-charges you insane amounts.
My $5/month VPS has 35TB of free bandwidth, and I pay $1.37 per excess TB. Similar speeds to when I used Vercel, but with a monthly bill with less 0's :)
Also, funny how he is nitpicking on a single functionality that is glitchy. YOU CAN DO THE SAME WITH REACT!!! Specially on components you render that need a network request to render the final version. Has this guy built anything that he can call a business other than a TH-cam channel???? We have gone from creators to "B.S content creators".
do you work for vercel?
To me,
A. The complaint about how every keypress goes to the server says literally nothing about HTML over the wire. It’s obviously how Hey chose to do things (or it was a bug), but Theo should be experienced enough to know that most approaches don’t need to be like this. Attributing a sloppy implementation by Hey onto a video about Rails as a whole is inflammatory.
B. And if he isn’t, and doesn’t realize that HTML over the wire doesn’t mean you can’t have any JavaScript, he should stop talking about what he does not understand.
C. This is personal taste, but a man with his hair style shows he can’t recognize good taste if it hit him in the face.
They sponsor him, yes
@@liyatini that explains a lot :)
@@TheVimeoI'm sure Vercel is very happy with him with the amount of teenagers he brings in that don't know how much Vercel up-charges the services they resell under a different UI 😅
@@liyatini is this is js universe is fucking sad.
the dude is like trump. yells and cry, lies, lies, and big ego. everyone is shit, look how cool and smart I'm
has a nice moustache at least :)
PS: his cool startup, if you do on network, just expose to private channel, that is funny :))
6:40 the chrome network presets do change latency and you can customize it with a custom profile.
This is not helpful. dhh not being correct doesn't mean we have to respond with mocking
Almost all these problems can be fixed with a Loading indicator (and disabled while loading)
bad ux
Linear with the same throttle takes 2 - 3 minutes to show anything at all.
Now what do you think the regular user will mind more? That depends for everyone, but I definitely would prefer the site where it just takes a little longer for a modal opposed to one where I have to stare at a void for 2-3 minutes.
Do you understand you don't have to use hotwire with rails? Feels like you haven't generated Rails project..
Why on earth does HEY do network request on each keypress 💀
That app is embarassing. How can they ship that and think it's fine...
Yeah, they could've atleast implemented a debounce.
My best guess is that there's some real-time validation going on (scanning for prohibited words and possible injection/attack vectors? but why would you do so real-time if there's no feedback to the customer anyway?) and since they proudly boast no client-side JS they have to send the text to the server for validation.
DDos as a service
Interactive.. bro, come on. 😂
I am a Laravel developer, i used all there is, Inertia, full separation API + SPA, Livewire, Hotwire( is framework agnostic), HTMX. All i can say is that Laravel + Inertia or SPA gives you full controll over everything, you want something except static (by default, you can get there but it is not a default), you want SSR, React SSR or React SPA? All these 3 you can get with Laravel and Inertia, all 3 at the same time, you don't have to choose one! What I see unfair is saying that HTMX crosses the bridge more then Hotwire or Livewire. All 3 of these are all the same, Hotwire and HTMX are framework agnostic and Livewire is for Laravel only, all 3 allows you the same amount of stuff and have the same amount of limitations, the big difference is the DX, Livewire + Laravel is way better then any other approach, both for developing and testing, but as a drawback, it limits you to the Laravel framework.
What i am trying to say about HTMX is that, if Hey was written in HTMX not Hotwire and they wanted that pop-up to still be rendered on the server, it would have been exactly the same experience. Same with Livewire. The only thing different was how you write when and what get's rendered there. The biggest problem with Hey is that their app renders 20 lines of HTML is over 300ms, and that is just bad, and i come from PHP, for me having more than 50ms in the same region to render HTML (Authorization being counted in) is just horrible.
You can use Inertia with Rails as well, since Inertia is framework agnostic. It’s pretty dope!
@@angelurena indeed, it's an incredible tool.
Hey @t3dotgg and @ThePrimeTimeagen!
Could you please do a video about HTMX vs Hotwired+Stimulus+Turbo?
What you recommend Inertia over it?
What are other solutions if you render html on server and if you don't want it to be written in javascript?
It was fine. It took under two seconds. You guys are dramatic.
If it was a NextJS app that had a 2 second throbber to load anything at all he'd be ecstatic about it
This is an insane thing to say. That's 2 seconds of time to the system to respond to stuff. As someone in a remote area with a bad internet connection (~600ms ping), I would find HEY to be infuriating to use. I'm sure other actual users that live with bad internet connections would, too.
@@CatFace8885 Try opening a JS framework site with that ping and enjoy waiting like 5x as long for the website to even open in the first place
On the other hand, I can't stand UIs that pretend something has happened before the server request has actually happened. Show a spinner or something but don't just pretend it's happened (i.e. don't move the HEY event until it's processed on the server or show it moved but greyed out or with a spinner _and_ move it back if it fails).
It's completely confusing and leads to potential data loss etc..
Your VPN isn't really a fair test since the data has to be sent to the location and then all the way back to you, so the latency is essentially doubled.
I agree that I would never choose to build an web app the way they have either and I also find DHH posts to be annoying, but I am a paying customer for Hey because I still enjoy the user experience more than Gmail. The latency isn't bad where I live and if I ever travel, since I just use Hey as a Gmail client, I can just log in to my email on Gmail instead. That being said, the only time I've ever felt the need to do that was on a Starlink internet connection in the middle of nowhere.
Uploadthing has a lot of the same quirks with user interaction with no pending state allowing for multiple submissions without knowing it. Most of these issues are less JS vs. Rails and more attention to detail misses. We all do it, ship fast and forget. This is not blaming anyone it’s more just saying we live in a world where there is no restrictions to what can be posted on the internet and therefore we also live in a world filled with jank 🤷
Latency is often way more significant than bandwidth. In the past I've sometimes had to bounce an SSH connection off a GEO satellite! So... f-ing...slow!
Hey theo the latest angular 17 and 18 revisions have been focusing more and more on server side rendering. I think you might need to do some explaining
What’s strikes as very strange to me is that Hotwire indeed provides all the building blocks to make the UX for Hey not suck (via stimulus), and yet the company that created it doesn’t seem to do it well. That being said, I currently write ruby/rails for a living and agree people default to relying on the server way too much.
Stimulus sucks for anything complex. It's really not a good replacement for a reactive front end library.
@@SeanLazer It's not supposed to be a replacement for React/Angular so I'm not sure why you would even say it's not a good replacement. It's closer to jQuery than React.
@@jl789nz because 37signals doesn't use any frontend libs and don't provide any official bindings for using them a la laravel and inertia. Stimulus is "the rails way" for doing your client side code
Problem is definition of suck is different of everyone. I’ve used Hey for years since it launched and it works smoothly.
I just learned that VPN breaks physics and that connecting to another country adds no latency because the latency between the VPN exit node and
my browser is zero! they must use quantum entanglement to pull this off. 🤦
I screamed out loud when I saw this... lalala "Now we're in France" wtf, anything for content.. unsubscribed..
@@Frexuz how does a vpn not add latency?
@@thabo256 i meant Theo, as in, i agree with the comment above
@@Frexuz ok but i think he mentioned this when he connected to austrailia
The point was to simulate a slower connection, like someone’s shitty LG phone, which is used by a significant number of people as their primary internet connection. Even if we go a step up for satellite internet (non Star Link), it would still feel slow. No one said anything about how VPNs work as that wasn’t the point, but I guess that flew right over your head.
I think in the end it's about a feeling that things are fast rather than making things faster when data needs to be saved on the server. The main difference in this comparison is how quickly the user gets a feedback that something is happening. This is vastly better in case of GCal as things seem to happen before they're done. GCal also has more animations that make the user feel that things are actually happening when you're actually waiting for data to be transferred.
Can someone explain why everything needs to be in a browser? A mail client is a perfect example of a native app that works way better than any web based solution ever could. The same goes for vscode and other example of heavy client side apps. If something is that client heavy why not simply develop it as a proper program/app?
Because accessibility. User don’t want to install new apps for everything. I prefer gmail in web than outlook or mail client,
@@chakritlikitkhajorn8730 I am not sure about that one. If it is easy to install many will just install an app. On phones that is very common, but due to the headaches program installations on windows are, many people don't think the same way for desktop apps. I would say that if it's easy to install most will prefer to just get the app for the best experience. If you are at the point where you install a browser extension to use a mail client site, you might as well download a full mail client. The only difference is that the extension will slow down your browser on every page load even if it is just a bit, in exchange for being easier to install.
That laugh on 13:36 smells abnormality even through a vpn.
36k views and barely makes 1k likes. Dude sit down we all know that next js is paying you.
29:30 Yeah the real issue for them isn't shipping JavaScript, it's writing it
I have some honest questions:
1 - If rails hates js why when you are creating a new rails app you have the option to setup the app natively with esbuild, bun, rollup or webpack?
2 - If rails hates js why the majority of projects i already worked on was rails with vuejs?
3 - why you used an example "laravel + intertia" when intertia has adapters for both laravel, rails?
4 - what is the sense of relating a product ux testing with a web framework? HAHAHAHAHAHAAHAHAH
I love your content Theo, but being a fellow Australian, I am offended by the way in which you said "Brisbane". I have never heard it said in such a strong American accent before haha
Could be worse, could be Melborrrrrrrrrrrrrrrn
@@sevenseacat oh god, don't even get me started 🤣
Fellow Australian? Theo is not Aussie is he?
@@yawaramin4771 No, I was talking about myself.
The network request on keypress thing is the kind of crap I would expect from code that was written by a LLM without any human input.
After watching some of your videos I'm starting to question just how knowledgeable you really are... This comes off more as a fan boy hater rant honestly.
I've been building websites since the early 90s and I've been working on and off with Rails systems for two decades now, including fully responsive client heavy systems which got tens of billions of requests a month. Not sure how bashing Rails over what is clearly just bad site design is supposed to accomplish other than making you look ignorant. You can still have a shitty site even if you run everything in the client.
Running everything in the client doesn't make it magically better. How magical is it when the client just "fakes" the updates and the server calls fail in the background? Or even worse things get magically undone after the server call fails. That's an even worse experience when it looks like you actions instantly happen only to revert seconds later. Heavy clients are not a magical fix and can suffer all the same issues in reverse.
It all comes down to proper architecture, design and using the proper tooling and solutions to accomplish the goals set forth. Just because you can do something doesn't always mean you should. If the goal is to have a super responsive client heavy application then one should use the appropriate technologies to accomplish that. If you want to avoid being client heavy then one should again use the appropriate technologies to do that. Painting yourself into a corner with hubris and bias is the hallmark of a bad and ignorant engineer.
It's always a balance; both approaches come with trade offs. Being client heavy gets you responsive apps in theory, but also a slew of browser compatibility issues; slow devices with limited memory also tend to run client heavy apps slowly. As mentioned if calls fail you can have things look like they updated only to have them undone on a refresh (or if the app is written properly seconds later). Server heavy apps, while slower, provide better resilience and integrity as you can be assured it won't update until the server is updated. It's always a trade off no matter the approach.
One thing I can say for certain, based on metrics for client heavy systems I've worked on with global reach, the average consumer is on a shitty device which often tends to process those client heavy apps way slower than one would ever expect. Most people have cheap or old computers and phones with slow processors and limited memory. The most recent Rails system I worked on did surveys in major mobile games globally (think rewarding in game currency for answering questions) and was completely client heavy where Rails was just a JSON API backend effectively. The average response time for Rails was 40ms; the average render time in the JS client was 2-4 seconds.
Sure for a bunch of tech bros in SF on gigabit connections running the client on the latest hardware with plenty of memory it's easy to make the argument you are making; but in the real world with hundreds of millions of consumers spread across the globe the answer is never that clear cut. To think otherwise is asinine.
You seem to focus solely on the latency when in reality the client's hardware and memory has the biggest impact. If you perform the same client vs server tests on shitty/old client hardware the server will win every time. It's all subjective as fuck no matter what argument you want to make. There is no right or wrong way; you just have to strike a balance based on the lowest common denominator if you want a decent experience for everyone. Of course if your only consumers are people in SF on gigabit with modern hardware then client side is probably the right call; however if you have a business that reaches people across the globe on mobile devices you're not gonna have a good time with that.
Your personal bias is on full display with this one. Try checking your ego and hubris at the door and stick to the technical merits because this just makes you look like a clown and hater who doesn't even understand the basics of technology or how to build sites and services.
One thing I've learned after being in this business for three decades; there is never a right or only way to do anything - and anyone that says otherwise is either inexperienced, ignorant or a fan boy trying to sell you something.
Notion being in the "local first" category is hilariously
In Chrome Dev Tools you can specify a custom profile for which you can change the latency as you like.
At this point, I just think Theo has a crush on DHH.
Does anyone know what that tidy looking sketch app he uses is?
Bashing rails without knowing rails lol. The tweets mentioning that Vue have easy pairings with React etc. Rails ALSO has that if you want :) Or just use the awesome Stimulus framework. It has nothing to do with Rails being anti-JS, because it's far from it, but the choices of how Hey was implemented.
thunderbird : A great premium experience, offline and free, running on all platforms for 20 years
5:57 - You raise a great point, many people don't consider the impacts on latency, and the sometimes surprising impact it can have when there's a lot of back and forth. There's even more metrics that go into an internet connection than just bandwidth and latency too. Loss is another metric which can impact in profound ways when compared to latency or bandwidth. For realtime applications you also have to consider jitter (change in latency over time).
nice video, the best thing is the diagram you made about server side and local apps, and the whole spectrum!
I understand hating React, but hating JS so much that you want everything rendered on server is very limiting mindset. There is the reason why this kind of architecture is so dominant, it didnt appear out of thin air.
Not saying I agree with all the Hey decisions in the video, nor if it would be great to build this in React or Vue, but this constant shaming of technologies that people don't use nor even want to use is such a negative vibe in the tech-industry. Just keep using whatever technology makes you happy bro.
I don't think you understand networks my man because the 'tests' that you create to prove your points don't prove what you think
HTMX is a bridge to where? How?
Totally accessible through exact points and descriptions, you made, even for a noob like me. Thank you. Keeper.
I have no quarrel with rich clients that provide a smooth experience to the user and enable clever offline. I do have a quarrel with doing it in an inadequate language such as JS/TS.
Don''t know theo but have watcned some videos of his. I am assuming I am missing something. How could someone with a technical background not udnerstand that when you use a vpn in another country you are connectin to a server there FROM THE US? so what in the world did testing for that do to show actual performance in the country?
the idea of needing to go to the server just to show a dropdown is absurd to me.
even the dropdown content is static, there's nothing on that dropdown that needed data from the server, you could literally just include it in the html or js then toggle it on click
I don't really care about Rails and haven't even looked into it, but I find it really ironic that React devs are so horrified about this when this kind of awful performance and bugs can be witnessed in many React applications as well. :D
If the literal creator of React built a really bad React app, then claimed we were all wrong and dumb when shown how bad it was, I would be just as annoyed.
Literally every technology can be bad if implemented incorrectly, your logic can be applied to anything. It’s not if there aren’t a ton of poorly coded C++ applications, don’t get me started on some JAVA apps. I’m talking apps where the client is built with these languages, not the server side. I’m mostly talking desktop software or purely native apps (coded in JAVA/Swift coded, not React Native) mobile apps. No one wants to talk about how many bad client side desktop apps there are though, do they? Especially back in the day before the web really started taking over application development.
@@t3dotgg Yeah I get that. But still I can't help but feel that both parties are resorting to some degree of whataboutism and saying everything is way worse on the other side.
@@some_dude__ true
Theo has such unnecessarily hyperbolic takes.
As a Rails dev I totally agree. Rails makes great APIs but I've always hated it's frontend. The "helpers" are confusing and frequently misused, the templates are simply worse than anything modern, and Ruby is comically slow. I also miss static types, it makes it hard sometimes but it's not the end of the world like some people say. If I'm using Rails I'd rather have a JS framework as a frontend, but Rails + React will never be better than Next
I recently started using view components that github released with rails. It's so much nicer than default templates for so much modern stuff.
Did he really use a VPN to test Internet speeds in Europe? Even I know it doesn't work like that.
1:40 not sure what the fuss is about. It’s super easy to add progressive front end interactivity on server side rendered apps. No framework required. Though Vue.js does make client side interactivity super easy.
Anybody know, what tools Theo uses to make flow chart/diagram like in the video? TIA
Excalidraw
Thanks @@shimadabr
I think the best pipe analogy would be bandwidth is the pipe's thickness, while the pipe's length(instead of water speed) is your latency, as you don't really change the volume of data you can receive every second, but the distance the data has to travel to get to you is larger
I'm not saying this product provides a good user experience. But I think 100/1 people care about it. And I'm sure DHH has thought about that a lot. And as developers, yes, we should care about it. I don't know.
old gen: auxiliary -> terminal -> graphical -> hypertext -> im still learning.
new gen: i know everything -> rich-internet application w/ graphical widgets and augmented multi-dimensional reality-*breaking*...
As an Australian, it’s Bris-bn. Content great as always I just need to do my civic duty of teaching pronunciation
I think I can forgive this, but why is this even a RoR issue, just design pattern 🤔
6:41 you can set latency, throttled 3g adds about 300ms I think? You can even set packet loss rate in modern browsers
Did you not know desktop email clients exist? Writing emails on a plane was never an issue and pretending that everything has to be a web app is not just idiotic it is feeding this "you own nothing" rent seeking that has almost become the norm. These nickle and dime fees have gotten so bad there are services just for tracking all your subscriptions.
Angular does SSR now btw and will eventually end up more and more like Qwik. They are merging with Wiz
I've had to use a satellite internet connection with >500ms latency and only around 20-50kbps bandwidth for work. the number of modern websites that weren't just slow but straight up didn't was ridiculous.
10:55 It takes a bit longer the first time because it lazy-loads some JS, I guess the drag-and-drop logic?
Have you heard about a thing called email client? Like superhuman is some kind of magic and Thunderbird has been there for ages.
What software is he using for drawing?
That person throttled their connection to demonstrate that...
But have you seen those cars tho
The fact that you thought using a VPN to connect to Europe would somehow magically allow your packets to teleport over.... and when you're comparing against google as an example of one being better than the other... uh no they're both garbage ~ the fact that you were probably being served by some nice google server in Sydney (sub 200ms per request) versus god knows whatever server that was giving you 400-500ms responses is reason one seems better than the other. Have them swap servers and you'd thing it was google doing something wrong...
Wait I thought we agreed vercel's dashboard is great
Brandon Roberts is a hero in the Angular world
You can fix the frontend bugs.
- Add a delay to the requests that are sent out as you type so that a request is made only when the typing has stopped.
- Drop the event in the new position and if the request fails move the event back.
- Preload the new event html and just display when the button is clicked to avoid.
It's more skill issues and bad QA. I've seen bad code from JS frameworks, too. The framework doesn't fix the developer.
It can’t be that trivial, if the company behind the product, isn’t able to do it properly
Google has servers in Australia too, so it is not quite fair
yes but the requests need to go back to his computer in SF
His request goes to the VPN Endpoint in australia, then to the google server in australia and from there back to the VPN Endpoint and only after that to him in SF.
@@mind.journey yes but hey must go to Australia and back to sf
@@AK-vx4dy If google only had server in SF, it would be like this:
Theo (SF) -> VPN (Au) -> Google (SF) -> VPN (Au) -> Theo (SF)
But, because Google has servers in Au, it's like:
Theo (SF) -> VPN (Au) -> Google (Au) -> VPN (Au) -> Theo (SF)
So you remove the latency from the VPN servers to Google servers, but the packets still need to travel to Au and back to Sf.
This is still fair because you can simulate what happens in a normal case where a user from SF sends a request to an Au server
@@Hapkumdo I try to tell that Hey may not have servers In Australia so request to hey is going to Australia, back to US then back to Australia and then back to sf again
It's just about how Hotwire was implemented in Hey, Theo! There is no silver bullet on software development. SPA is not the greatest thing in the world. There are situations where SSR fits better than others approaching.
Your channel is just for entertainment, but not to take it seriously. Sorry.
I don't think you can objectively test Google's infra against a VPN when they have "servers on the edge" of various worlds regions.
sometimes you might get a session to be sticky to a server in a non optimized region, but doubt it'll last more than two requests to mount to a closer server
The voice change after pressing Enter twice 😂
Where does the notion of Notion being "local first" come from? In my experience it doesn't work at all with no Internet connection. Neither the web version nor any of the apps.
A much more deserving candidate to shit on tbh
It was saying Notion SHOULD be local first. It isn’t and it’s one of the biggest pain points I have with it
@@t3dotgg I see. Totally agree
27:20 Any app that has input that users invest more than a few seconds on should support offline mode probably
Also if you already have an iOS/Android full native app, it makes way more sense to treat your web app as just another platform
27:00: I do that with thunderbird 🤷
7:12, just an fyi from an Aussie, 'Brisbane' is pronounced as briz-bin or briz-bən (or briz-b'n if you're especially Australian) and never as briz-bane
Yeah, but you're saying it wrong. It's "briz-bane" because America is the best country and our pronunciations are therefore the best. 🇺🇲
As someone who frequently has 300+ ping (but great bandwidth) to servers, it's often painfully obvious which sites are relying on the server being fast.
I'm not saying you're wrong on all accounts, but man.... it's a successful paid product - that's what matters first and foremost.
It works. You're putting it to the test under weird constraints at time. Also, a lot of those you can fix if it truly matters for the UX.
All in all, I find this a cheap stab at Rails.