I think it's less of a distinctly populist thing and more of a "convert's zeal". I have seen this type of language used with a lot of different technologies over the years when there's a lot of hype and momentum around them.
Ultimately there's just a lot of tradeoffs to make in this space and I'm glad that we have more options now. For awhile it seemed like you were either doing SPAs or everyone thought you were doing it "wrong", but things like HTMX, LiveView, Livewire, and Hotwire make it much easier to build good backend driven web apps.
Inertia.js 2.0 is a really compelling middle ground as well & IMO is the best thing to come out of Laravel. You can get most of the benefits of a JS "metaframework", but you have adapters for many different backend and frontend frameworks.
Inertia is a godsend. We are using it at work and it’s such an amazing combination of the best of both worlds without all the craziness going on with the more popular meta frameworks.
Browser Company sort of built this themselves for Arc, but its really a separate SwiftUI-like Windows implementation (Windows UI is separate code written in a similar style). It still feels like a technical preview though unfortunately.
How do you ban AIPAC when they are basically malware that is running at all layers of the stack from OS to Firmware to CPU Microcode? Good luck with that!
There's no evidence of that happening & it really isn't even about that. It's about the popularity of pro-Palestinian content on TikTok. The other social media giants have censorship policies on this that tilt things towards a pro-Israel perspective, but TikTok does not and is being targeted for it.
What is even the point of the Blazer EV if it is essentially the same vehicle at the Cadillac Lyriq at essentially the same price? When they announced this thing they said it would be $45k, instead its almost $60k just like the Lyriq. Not sure if there's a difference in quality of materials, sound deadening, etc. It is technically a couple thousand cheaper, but it's also made in Mexico with non-union labor instead of made in the U.S.
They're still claiming the Equinox EV will be available at $35k mid 2024 but I'm highly skeptical of that at this point, unless they plan on selling them at a loss.
> They're still claiming the Equinox EV will be available at $35k mid 2024 but I'm highly skeptical of that at this point, unless they plan on selling them at a loss.
I was curious about this also. It's a nice-looking vehicle, and the pricing does seem pretty aspirational. I figured they will force you to go up a trim level or two to get basic safety features like a blind spot monitor, or common features like dynamic cruise control.
Even though it won't have CarPlay, I would consider getting one if the price of a decent version is close to $35k.
State (eg: California) mandates that a certain percentage of cars sold be EVs. That naturally means a certain percentage of cars manufactured for subsequent sale have to be EVs to accomplish the sale percentage mandate.
You can't make sure 30% (note: arbitrary number for sake of conversation) of your car sales are EVs unless at least 30% of the cars you manufacture for selling are EVs.
Isn’t “sold” the key point though? Why make a worse car for marginally less instead of making more of the good cars that are, by comparison, a much better deal? They would be easier to sell…
If this was actually about safety they would just get rid of the touch screen entirely. You really don't even need a display at all anymore, HUD + physical controls could cover all essential functions.
If it were up to me, I'd mandate that all cars are required to have a HUD. HUDs are insanely useful, mainly because it doesn't require the driver to take their eyes off the road for directions or for checking their speed.
Elon refusing to put a HUD in the tesla's is one of the reasons why he shouldn't be the CEO of anything, let alone a car company.
Once you've owned a car with a decent HUD, it really does feel insane to go back to a car where you have to look away from the road for something as basic as checking your speed. It's a great feature.
I'm probably in the minority of the minority, but I don't want a touch screen in my car. Or even any big LCD screen in my car. I would prefer my car to be relatively dumb, and free of distractions where possible.
This scenario does seem like something that would be cacheable to me though. Really its a matter of where you're doing the caching -- on the server, or in the client. It's easier to manage cache invalidation (and state in general) on the server so that seems like the preferable option to me for most things.
In the context of Rails specifically, something like Solid Cache helps a lot with this too. There are other similar approaches for other languages/databases as well, although most implementations are based on Postgres instead of MySQL.
If the specificity & complexity of the query is the barrier to caching, it's also possible that breaking the query up a bit could still net better performance if it makes it easier to cache.
> This scenario does seem like something that would be cacheable to me though
The table of contents has a course with sections, lessons and downloads / videos with sums of video lengths that roll up to each section and back to the whole course. It rarely changes but the monkey wrench is there's a checkbox next to each lesson where a user can toggle a lesson as being complete so now it's really personalized for each user with a model storing this state. I didn't want to save this client side in local storage in case they watch things on multiple devices.
Having a separate cache for each user seemed like it would be a big mess, especially since these "lesson completions" move very fast in the sense that a user can toggle a handful of them per session. This table is also pretty big. Imagine having a 200 lesson course but you have 10,000 people who took it. Now we're at 2 million rows. Russian doll caching seemed pretty dangerous here, I'd have to have touch: true on like 5 cascading models where editing 1 thing would bust components of the cache for everyone.
The queries themselves aren't too complicated. It's pretty much 3 queries with "includes" being used at times to avoid N+1 queries. It's getting the course, then looping over its sections and then looping over its lessons and in that lesson loop it gets any downloads. Then there's the lesson completion state for the current user too to see if it should be checked or not.
It doesn't seem very friendly to being cached.
I really wanted to avoid having a single cache for the whole TOC and making a separate ajax request to load in the user's lesson completions after the page has loaded. The UI gets jittery with the checkboxes being populated afterwards. This also opens a few cans of worms. Even if this were to happen in the end with Turbo 8, I'd still have to query the per user lesson completions + all of the resources (questions or show notes, etc.) presented under the video on every page transition.
I don't know all the details of course, but I think I'd approach this by splitting the user specific info into a short lived user specific cache + globally caching the non user specific stuff for a bit longer. Ideally that way you only have to query the user specific part at most once every 5 minutes or something like that.
Or even if you didn't cache the user specific bits, you could cache the rest and just query for that every time.
Other dom morphing setups have the concept of "ignore this sub-tree" which means that on first load you can render the ToC and checkboxes for the user, but then on the AJAX requests from Turbo omit that section of the page entirely. This lets you cache and share them whilst when the user refreshes the page they get the latest ToC.
It adds complexity but then if you need caching, what doesn't?
I'm not familiar with that omission process. What would that look like in practice?
It sounds like I'd still get a poor UX on the first page load (UI checkbox jitter), and on all page transitions I'd need to run the user specific lesson completions query produced from the ajax request and all of the other heavy content under the video (questions + show notes, etc.) would need to get rendered which in the end is much more expensive than using frames to avoid any of that from being processed.
I'm not trying to make the case of sticking with frames + streams either, I think it's been kind of painful to use them with all that's going on within the page. I'd love to be able to use the morph approach. I think I'd be able to delete tons of both server side and client side code.
Turbo morphing will allow to do exactly that, exclude a section from morphing, by wrapping it in:
<div data-turbo-permanent>...</div>
I think it's not yet documented since turbo has not yet landed in a production release of Turbo but it's been merged into main, you can see it mentioned on the PR: https://github.com/hotwired/turbo/pull/1019 (Look for "Exclude sections from morphing" title in the PR description).
Hybrid sales are way up, that’s where the growth is going to be the next couple of years. The strategy that everyone was calling Toyota insane or even evil for is starting to make a lot more sense looking at market trends.
Ultimately there's just a lot of tradeoffs to make in this space and I'm glad that we have more options now. For awhile it seemed like you were either doing SPAs or everyone thought you were doing it "wrong", but things like HTMX, LiveView, Livewire, and Hotwire make it much easier to build good backend driven web apps.
Inertia.js 2.0 is a really compelling middle ground as well & IMO is the best thing to come out of Laravel. You can get most of the benefits of a JS "metaframework", but you have adapters for many different backend and frontend frameworks.