Intercepting clicks on all anchors and then replacing the body is something the browser should do and not the javascript library.
Hotwire: HTML over the Wire
491–500 of 573 posts
Re: Hotwire: HTML over the Wire
#492Earlier quoted context omitted.
> If by surprisingly little, you mean 4 pages and 500mb of requirements for a "hello world" project with the "modern" web, then yes. React is well under 20k. FWIW when optimizing my SPA, my largest "oops" in regards to size were an unoptimized header image, and improperly specified web fonts. There are some bloated Javascript libraries out there, yes. But if you dig into them you will often find that they are bloated…
Ah react, the biggest crap of them all. A 12 year old with basic programming skills is definitely capable of designing a better "framework". Yes, everything frontend is quoted because it's nothing more than a joke at this point. Back to react, and ignoring all the underlying problems coming from the pile of crap that is js, let's kick things off with jsx. The fact that someone developed their own syntax(I'm not sure…
> Ah react, the biggest crap of them all. A 12 year old with basic programming skills is definitely capable of designing a better "framework".
You're literally a stereotypical Hacker News commenter. I also find the modern frontend a bit too complicated but this is just an unreasonable statement.
Re: Hotwire: HTML over the Wire
#493I wonder how long it will take before we reinvent SPAs? I like Hacker News in part because the tech is so boring. Server-side rendered, static HTML with a minimal amount of JS[0]. [0]: https://news.ycombinator.com/hn.js
I also prefer boring and love how HN works. That said though, modern consumers expect much more. We tech people like command lines, the ultimate in simple and boring. Modern consumers often want animation and things[1]. Source: UI/UX researchers tell me this when I push back and say "let's keep the tech simple and forgo some of the animations, etc in the name of using simple OOTB stuff without hacking thousands of li…
Not sure since when undiscoverable command line interfaces are simple. Simple to make, yes, but not easy to use compared to the most basic visual solution where its creator put a lot of thought.
Re: Hotwire: HTML over the Wire
#494Earlier quoted context omitted.
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…
These companies might hire people as an edge against any future competition. Talented engineers are tied up doing menial tasks but getting paid $300k/year, cheaper than having to compete?
There's only a handful companies out there who might be doing that, namely Google, Facebook and a few others. No other company is at the scale to meaningfully affect the market.
Re: Hotwire: HTML over the Wire
#495Lol. I made something similar: gihub.com/sloev/cccp
As in sssr as in semi server side rendered
Re: Hotwire: HTML over the Wire
#496Earlier quoted context omitted.
Ah react, the biggest crap of them all. A 12 year old with basic programming skills is definitely capable of designing a better "framework". Yes, everything frontend is quoted because it's nothing more than a joke at this point. Back to react, and ignoring all the underlying problems coming from the pile of crap that is js, let's kick things off with jsx. The fact that someone developed their own syntax(I'm not sure…
> Ah react, the biggest crap of them all. A 12 year old with basic programming skills is definitely capable of designing a better "framework". You're literally a stereotypical Hacker News commenter. I also find the modern frontend a bit too complicated but this is just an unreasonable statement.
You'd be right if I had not given arguments for my statement. I did as a matter of fact.
Re: Hotwire: HTML over the Wire
#497Earlier quoted context omitted.
It is. But he also wrote this in a subsequent tweet: > For a typically long running app like an email client, the obsession with shipping as little JavaScript as possible is actually detrimental to the end UX.
I'd argue that's almost objectively true. For a long running app, initial load time isn't as important as something like a ecommerce store.
Hey probably is the worst example for this approach, even though it works and it's impressive what they were able to achieve. It should be much better for most website out there that aren't trying to be a low latency app you run 24 hours a day.
Re: Hotwire: HTML over the Wire
#498I looked at several html-over-the-wire frameworks during the last weeks and wrote down my opinionated perspective.
I think I will go with htmx.
If you want to know more: https://github.com/guettli/html-over-the-wire
Re: Hotwire: HTML over the Wire
#499Earlier quoted context omitted.
> But... that's one of the pro's of not having to do the rending cycle on the server. Also caching of framework libraries off CDN's and such. This doesn't save battery life on a device. If someone downloads a few meg of JS their browser has to parse and execute that JS locally. This use of processing uses power. If that same person had half as much JS to parse and execute it would use less power. A CDN does not save…
I think there's some kind of weird mentality among web devs that client-size computations are free, but server-side ones cost resources because you do more of them the more users you have.
That’s not so weird. It’s like IKEA shipping you disassembled furniture: they don’t have to pay for assembly (nor for shipping as much air). The client bears the cost of assembly, so if you don’t pay the client’s costs, it’s free.
Re: Hotwire: HTML over the Wire
#500As 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…
This! I am not a fan of SPA everything. This looks like a great framework for web only. But as you said, what about mobile development? Sure they are still going publish Strada. But will it also work, for example, with Flutter without additional friction? How about services that need to consume output from each other? I believe parsing HTML is more expensive than JSON.