Live data from Hacker News

Breaking up with JavaScript front ends

triskweline.de

11–20 of 433 posts

Re: Breaking up with JavaScript front ends

#11
Seems 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 route. Not this.

[1] https://htmx.org/.

[2] https://javascript.works-hub.com/learn/a-javascript-free-fro.... https://slimvoice.co/

Re: Breaking up with JavaScript front ends

#12

I would love a way to view this exact same content as a long form vertical scrolling article/post rather than as a virtual slide deck.

Yeah, perhaps if only there were a structured markup language that could be used to provide this information in an accessible manner with separation of concerns between content and display.

Re: Breaking up with JavaScript front ends

#14

Warning: if you want to look at the content of this page, say goodbye to your back button.

yeah, this was particularly ironic.

The back button has evolved alongside SPAs, and users mostly don't expect or want their back button to take them back through the hundreds of small state changes they've caused by interacting naturally with a UI.

Re: Breaking up with JavaScript front ends

#15

I would love a way to view this exact same content as a long form vertical scrolling article/post rather than as a virtual slide deck.

Yeah, perhaps if only there were a structured markup language that could be used to provide this information in an accessible manner with separation of concerns between content and display.

impossible!

Re: Breaking up with JavaScript front ends

#16
post #11

Seems 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'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 understanding of why and how we got to where we are, and the tradeoffs that were made along the way.

Re: Breaking up with JavaScript front ends

#17
post #11

Seems 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'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…

SPAs solved a labor problem I think. It was the reason that front end development grew so fast.

It is much faster to train people on a combo js+css framework rather than training someone on backend languages, databases, queues, authentication, scaling + html & css for server side rendering.

Re: Breaking up with JavaScript front ends

#19
post #11

Seems 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'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 tools are vanilla express apps with very little client-side code.

It's true that a lot of newer devs really don't have a great deal of context for why React & company became the de facto default for building websites and how much we used to get done with largely server-based architectures. I wish we did a better job of teaching fundamentals here rather than bootcamping everyone straight into building SPAs.

However, it's also true that the baseline expectation for web experiences is a lot higher in 2022 than it was in 2009 in terms of the level of responsiveness, interactivity, and overall "app-like-ness", to the point where I think that even with the massive improvements in bandwidth, latency, and web protocols, we still need to accept that there are many cases where just shoving full HTML documents over the wire isn't enough to satisfy user & stakeholder expectations. That's where stuff like LiveView, htmx, and Web Components become interesting to me. The web has evolved, and finally the server-side-application paradigm feels like it's starting to evolve along with it, and these evolutions do feel like they're novel & useful enough to deserve being called "new ideas".

Re: Breaking up with JavaScript front ends

#20

Earlier 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…

SPAs solved a labor problem I think. It was the reason that front end development grew so fast. It is much faster to train people on a combo js+css framework rather than training someone on backend languages, databases, queues, authentication, scaling + html & css for server side rendering.

Or maybe people don't like waiting for a page to load each time they click a button?
Post reply on HN