Not to be confused with Turbo by Yandex: https://yandex.com/dev/turbo/index/, which is a competitive take on Google AMP.
Hotwire: HTML over the Wire
331–340 of 573 posts
Re: Hotwire: HTML over the Wire
#332This is so exciting to see, especially for older folk like me. Almost 20 years ago, one of my professors told us before graduation that hot tech is mostly about the idea pendulum swinging back and forth. I immediately chalked it up to 65+ above white wise men snobbery. However, this is exactly that. We started with static pages, then came Ajax and Asp.net and the open source variants, then we went full SPA, now we ar…
I completely agree with this. For reference, I'm a relatively new developer - 3.5+ years of experience in my first developer position. At the beginning of college everyone was SUPER into NoSQL. All my friends were using it, SQL was slow, etc. Nearing the end of college and the beginning of my job I began seeing articles saying why NoSQL wasn't the best, why SQL is good for some things over NoSQL, etc. Technology is c…
I just have no idea why this trend got so popular because in my undergrad CS program, we all had to take a database fundamentals class. And once you actually understand how databases implement transactions, rollbacks, atomicity, etc. and when you use said SQL databases and see how fast the queries actually are, how in the world could anyone convince you that a non-ACID database with no defined schema is better?
Re: Hotwire: HTML over the Wire
#333Laugh all you want but the hey.com website loads wicked fast.
Why wouldn't it? It's got like 2 pictures and isn't long. I also wouldn't call it wicked fast - this is normal speed, which everyone seems to have forgotten
Go ahead and load the hey login page.
The js bundle your browser downloaded right there is the entire bundle for the whole email app.
What size is it?
Re: Hotwire: HTML over the Wire
#334This is so exciting to see, especially for older folk like me. Almost 20 years ago, one of my professors told us before graduation that hot tech is mostly about the idea pendulum swinging back and forth. I immediately chalked it up to 65+ above white wise men snobbery. However, this is exactly that. We started with static pages, then came Ajax and Asp.net and the open source variants, then we went full SPA, now we ar…
>65+ above white wise men snobbery Nice! Casual ageism and racism mixed into one post.
Rough guess OP is making fun of himself with this now.
Re: Hotwire: HTML over the Wire
#335How do they intent to not have "Send massive files without using other apps" being abused? Isn't this one of the key reasons to use a separated system. I can see this becoming a big problem on their ecosystem if it starts to scale it'll start to be very costly.
They charge $100 a year. It already is very costly (for us).
Re: Hotwire: HTML over the Wire
#336Earlier quoted context omitted.
> You have the benefit of hindsight at this time. People have been pointing out it's a shit show with no end in sight for the entire duration of the phase. Pointing out the performance impact and cost to end users, how diabolical it is for those on lower latency or poorer network connectivity (i.e. most of the world), and so on. Same thing as always happens with these pendulum swings, newer engineers come in convince…
I guess I've become a grey beard. I've done the whole journey from CGI everything to a bit of js to SPA. As much as I'd really like to be nostalgic about the good old days, there are reasons everything got pushed into the client. One of those reasons is maintaining state. "HTML over the wire" isn't really a return to the good ol' days. It's still the client maintaining state and using tons of js to move data back and…
They mean JavaScript that you write.
Re: Hotwire: HTML over the Wire
#337As others have noted, seems reasonably similar to LiveView, Livewire and Blazor. I’m somewhat bullish on these approaches - server side rendered monoliths (Rails, Django, etc.) are SO productive, at least for the first few years of development, but lack of interactivity is a big issue, and this solves it well. However, another big issue is the dominance of mobile. More and more, you’ve got 2-3 frontends (web and cros…
> I’d strongly consider this for a web-only product, but that’s becoming more and more rare.
They have accompanying https://github.com/hotwired/turbo-ios and https://github.com/hotwired/turbo-android projects to bridge the gap.
Re: Hotwire: HTML over the Wire
#338This is so exciting to see, especially for older folk like me. Almost 20 years ago, one of my professors told us before graduation that hot tech is mostly about the idea pendulum swinging back and forth. I immediately chalked it up to 65+ above white wise men snobbery. However, this is exactly that. We started with static pages, then came Ajax and Asp.net and the open source variants, then we went full SPA, now we ar…
The interesting thing is that if you don't think of the browser as just another runtime, nothing more than The VM That Lived (where applets and flash died), but actually think of your applications as Web Applications, then you get the ideas behind this faster.
JSON is just a media type that a resource can be rendered as. HTML is another media type for the same resource. Which is better? Neither, necessarily, it depends on the client application. But if you are primarily using JSON to drive updates to custom client code to push to HTML, well, that should give you something to think about.
Re: Hotwire: HTML over the Wire
#339Most of the comments here are along the lines of: this is old tech! But this isn’t really about the tech, it as much a productivity hack that allows people to be much closer to that old fashioned concept of a full stack developer This is what has allowed Basecamp to create Hey with a team just a fraction of the size of their competitors
Somewhere along the way Mythical Man Month was turned from a cautionary tale into a competition, and it only ever seems to happen once VC gets their mitts on a company. Does it really take a team of 800 engineers to maintain your fancy todo list app, rather than your focussed team of 10 or 20? What are all of those people doing except piling on organisational cruft so the business has no choice but to over-encumber i…
At scale, yeah it does take a lot of people to do this. It has nothing to do with the type of app and everything to do with how business works.
At scale you have huge enterprise customers with complex setups and they want to integrate your fancy todo list app into their setup and will pay you tons to do it. Your fancy todo list app suddenly needs to have all sorts of security certifications, needs to guarantee some type of uptime, needs to be able to integrate with all sorts of systems and other products (some of which none of your current engineers will have experience with). A new device will be released (think Apple Watch) and you're leaving money on the table if you don't hire some engineers to put your fancy todo list app on that platform along with the 5 or 6 others it's already maintained on.
At scale, 1 in a million type bugs/problems come up every day and you need more engineers to deal with them.
At scale, you are generating and producing (and thus need to be collecting and analyzing) an amazing amount of data, which should be used to better your product, learn about your customers and try to grow your business into providing other products and services your customers want / need. All that data collection, storage, and analysis requires more and more engineers.
Re: Hotwire: HTML over the Wire
#340How do they intent to not have "Send massive files without using other apps" being abused? Isn't this one of the key reasons to use a separated system. I can see this becoming a big problem on their ecosystem if it starts to scale it'll start to be very costly.
They charge $100 a year. It already is very costly (for us).
$100 per month: https://basecamp.com/pricing