Maybe it's just me, but needing to press "back" twenty or so times to get back to HN after viewing some of this presentation really made me question the author's authority when it comes to "how the web should work".
Breaking up with JavaScript front ends
151–160 of 433 posts
Re: Breaking up with JavaScript front ends
#152Seems like a half-baked agency-built version of htmx[1], no? I'm actually very intrigued by the whole "let's take a step back and move a lot of our logic back to the server" approach to modern dev, but IMO when you need more than statically rendered pages, it should look a lot more like htmx or Phoenix LiveView (if you're using a framework) or something ultra-minimal like Slimvoice[2] if you want to go the bespoke ro…
I had this going back around late 2000s with jQuery and Spring Web Flow. It was absolutely glorious. Server side declarative navigation (great for dev coordination), seamless transitions, less bandwidth consumed, super simple client side rendering, no more issues with the PRG pattern and user interference, and I even think I put in even listeners to execute animations based on the return fragment.
Never was allowed to put it into prod - "didnt need it". Oh well.
Re: Breaking up with JavaScript front ends
#153The key question for me is not whether there is too much complexity, but whether or not this complexity is something that adds value for the actual user. Too many things do not actually do that. I use too many pages where I know it's some kind of an SAP simply because the user experience is buggy, clunky and shitty. Why that is, is a really big topic and there could be many reasons, but it's not really discussed.
Re: Breaking up with JavaScript front ends
#154I haven't scroll the whole way through, and am a complete novice to webdev but this is reminding me of htmx a little. Is it just me?
Re: Breaking up with JavaScript front ends
#155GOOD FUCKING LUCK
Re: Breaking up with JavaScript front ends
#156Earlier quoted context omitted.
>I'm actually very intrigued by the whole "let's take a step back and move a lot of our logic back to the server" approach to modern dev, What's old is new again. There's an entire generation of developers now who have no concept of the old world. They started with React/Angular/Vue and have no idea that SSR was the standard default for decades. And now it's a "new idea" that is held up against JS development with no…
I both agree and disagree with this take. I started out hand-coding static html pages, graduated to Drupal and Wordpress php stuff circa 2009 (glad that's over!), then worked on a largely server-rendered Rails SAAS in the APM space that I guarantee you've interacted with if you've been in the web game for more than a couple years. These days, I may sling React for my 9-5 but a lot of my personal projects and internal…
> However, it's also true that the baseline expectation for web experiences is a lot higher in 2022 than it was in 2009
Is it?. I think this expected behavior and increased complexity comes more from designers and product owners than from real actual users.
I, as a user, still enjoy a lot more the old Reddit (old.Reddit.com) than the new one. I even prefer hackernews than many other more “modern” forums that feel slow and bloated. And I also prefer the current GitHub to what I bet it will become the moment they start moving it to React.
Re: Breaking up with JavaScript front ends
#157I wonder how much traction we could get with a no-JS approach.
Re: Breaking up with JavaScript front ends
#158Earlier quoted context omitted.
Tools like htmx aren't the reason the gmail tab uses a GB of memory. You'll find the majority of cases where pages are using way more resources than it should, are due to reasons forced on web developers, like a billion different trackers and several different ad networks, and workarounds to ad blocking to sell more subscriptions, etc. This is what is so shocking to me when HN spends such an absurd amount of time ral…
According to my browser, the default view in gmail needs 8.32 MiB of javascript spread over 90 files to render. While IDLE, the gmail tab uses 10-30% of an M1 CPU core. That stuff is not down to tracking - it's because the damn thing keeps messing with the DOM, because it has some insane structure where javascript controllers are attached as strings to DOM elements, because it uses about 100 divs to render every row…
What browser are you using? Having Gmail open doesn't even use half of a percent of a single core on my machine (Linux, x86, Chromium).
Re: Breaking up with JavaScript front ends
#159Am I missing something? They say to "Start classic" or "Start enhanced" on the first page of the demo app but neither is there for me.
Author here. The link is a 6 years old presentation. The demo app has since been rewritten. The old demo app focused on the downsides of classic multi-page apps (MPAs), i.e. the reason the world moved to SPAs all these years ago. In an MPA clicking a link loses all transient state, like focus, scroll positions and unsaved form state. This can all be solved with updating fragments instead of full pages, while still ke…
Ah, mystery solved. Thanks.
Re: Breaking up with JavaScript front ends
#160Genuine question : Is anyone building a 10 year JS framework? Something similar to how we’ve had C standards - we had c99 and then c11 (followed by c17)