Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Breaking up with JavaScript front ends

triskweline.de

Post reply on HN
Print view View original

31–40 of 433 posts

Re: Breaking up with JavaScript front ends

#31

Post by zozbot234 »

qrohlf wrote: 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'd try to optimize logic on the client before moving more logic back to the server. This is essentially what Svelte and SolidJS do - they clean up a lot of the existing overhead of SPA solutions. Of course, rendering server-sent HTML as in the HTMX model (or perhaps HTML generated in-client via WASM) instead of doing costly fine-grained DOM updates could then be added as a further optimization.

Re: Breaking up with JavaScript front ends

#32

Post by ransom1538 »

jrochkind1 wrote: post #21

It's interesting that they appear to plan to use with Rails as a back-end (they mention Rails bindings), as Rails 7 release corresponded with a solution which appears somewhat similar to me, turbo/stimulus. (I want to provide a link to it, but I honestly don't know any great docs for it!) But I haven't used stimulus/turbo myself. I'd be interested in a compare/contrast between Rails' Stimulus/turbo and "Unpoly" cover…

"I want to provide a link to it, but I honestly don't know any great docs for it!"

I setup a demo, rails7/mysql[1]/turbo/docker - one command setup you are playing with it. https://github.com/james-ransom/rails7-on-docker-mysql. Give me a star you have a friend for life!

* not Postgres!!

Re: Breaking up with JavaScript front ends

#33

Post by NegativeLatency »

jrochkind1 wrote: post #21

It's interesting that they appear to plan to use with Rails as a back-end (they mention Rails bindings), as Rails 7 release corresponded with a solution which appears somewhat similar to me, turbo/stimulus. (I want to provide a link to it, but I honestly don't know any great docs for it!) But I haven't used stimulus/turbo myself. I'd be interested in a compare/contrast between Rails' Stimulus/turbo and "Unpoly" cover…

The readme seems to give a pretty good overview of turbo: https://github.com/hotwired/turbo-rails

Re: Breaking up with JavaScript front ends

#34

Post by skilled »

I think innovation needs to happen in package management. Has it happened yet? Because I don't know for sure, so I am asking because I might have overlooked it.

Even projects from a few months ago can be become unusable unless you are willing to sit down and spend a couple of hours fixing the problem. And don't get me started on packages that have been abandoned altogether but are like glue to functional software.

(I am talking about npm)

Re: Breaking up with JavaScript front ends

#37

Post by duxup »

ramesh31 wrote: post #16
qrohlf wrote: 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…

> What's old is new again.

I work on some old ColdFusion apps.

Some aspects feel very modern.

Re: Breaking up with JavaScript front ends

#39

Post by dpacmittal »

spritefs wrote: post #36

> We're breaking up with JavaScript front ends > Site doesn't load properly with javascript disabled They should put their money where their mouth is

I think it was about breaking up with SPA frameworks/libraries. The whole slideshow is about unpoly which is a JS library which provides SPA like experience without the complexity of a full blown SPA

Re: Breaking up with JavaScript front ends

#40

Post by JohnFen »

22289d wrote: post #6

If this page is a demonstration of what a future without JavaScript would look like, it's an unintentional advertisement for sticking with JavaScript.

I can't tell, because their site won't render without JS enabled, and I'm not willing to enable it for them.
Post reply on HN