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

Stimulus.js 2.0

discourse.stimulusjs.org

Post reply on HN
Print view View original

131–140 of 140 posts

Re: Stimulus.js 2.0

#131

Post by davidjnelson »

danjac wrote: post #130
davidjnelson wrote: post #123

Earlier quoted context omitted.

Ya it really depends. I like redis and Postgres generally speaking for data, and Ruby on Rails generally for business logic. And you can certainly do universal rendering with that easily with react_on_rails. If you do end up needing more perf, maybe go would be interesting.

Yes but we're still going a long way from "just use React". One benefit of the "JS sprinkles" approach of Turbolinks+Stimulus is that you have a far simpler and more productive stack: Rails (or other framework) renders templates with some minimal JS on the frontend, as opposed to the inherent complexity of API + SSR + SPA. There are occasions when React is a good choice of course, but let's not underestimate the cost…

hey if stimulus and turbolinks are your jam then rock it!

I would at least give this a look though, it's super easy to use: https://github.com/shakacode/react_on_rails

Re: Stimulus.js 2.0

#132

Post by davidjnelson »

cercatrova wrote: post #129
Existenceblinks wrote: post #128

Earlier quoted context omitted.

So your system have two backends, the React backend and the api server? That does not sounds like a good investment.

Works fine, the NodeJS server simply builds the React page, nothing more. The API does all the heavy lifting of course.

yup, and if you want to really optimize it you could use functions as a service like lambda as your react rendering layer, which forwards to heroku or fargate or beanstalk or vanilla ec2 or whatever for your backend.

and if cloudflare workers ever support metered usage you could use that too for the react layer.

and if you want hyper performance you could use lambda@edge and intelligently route to your backend running on fly.io to minimize the distance. the somewhat unsolved problem there though is multi region master master replicated databases which are cost effective.

to my knowledge this is the current state of the art for that https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide...

problem is you have to pay for each region so it's not really cost effective.

Re: Stimulus.js 2.0

#133

Post by cercatrova »

davidjnelson wrote: post #132
cercatrova wrote: post #129

Earlier quoted context omitted.

Works fine, the NodeJS server simply builds the React page, nothing more. The API does all the heavy lifting of course.

yup, and if you want to really optimize it you could use functions as a service like lambda as your react rendering layer, which forwards to heroku or fargate or beanstalk or vanilla ec2 or whatever for your backend. and if cloudflare workers ever support metered usage you could use that too for the react layer. and if you want hyper performance you could use lambda@edge and intelligently route to your backend runnin…

That seems overly expensive compared to just keeping a build server

Re: Stimulus.js 2.0

#134

Post by Existenceblinks »

davidjnelson wrote: post #132
cercatrova wrote: post #129

Earlier quoted context omitted.

Works fine, the NodeJS server simply builds the React page, nothing more. The API does all the heavy lifting of course.

yup, and if you want to really optimize it you could use functions as a service like lambda as your react rendering layer, which forwards to heroku or fargate or beanstalk or vanilla ec2 or whatever for your backend. and if cloudflare workers ever support metered usage you could use that too for the react layer. and if you want hyper performance you could use lambda@edge and intelligently route to your backend runnin…

I thought you were making joke about complexity when I read the first line, but then in the end it's not a joke. Why don't you have 1 single backend peacefully. JS sprinkles for what it needs to be interactive. (I'm tired of "complex form " argument, jQuery turned out ok back then, so does Stimulus or whatever works with server rendered html (e.g. vue))

Re: Stimulus.js 2.0

#135

Post by catwind7 »

Existenceblinks wrote: post #126
catwind7 wrote: post #117

Earlier quoted context omitted.

I don't know enough about which parts of the site you're referring to to say for sure, but stimulus / stimulus-like approaches are perfectly fine for most display-only views even if they're fairly complex. There are pages in our app where stimulus works great and the UI is fairly complex from a standpoint of the number of strictly user facing behavior (click this, show X, Y, and Z). The complexity involved in handlin…

I built complex form before on financial platform where it contains complex investment details, different entities for different kind of offering .. with vanilla javascript. But that may sound grumpy old man in argument. Stimulus' weak point may be where it requires many DOM mutation per action, that's probably better use declarative way to re-render the whole thing in different way based on data.

Not at all - I still favor vanillajs if only to avoid the bloat of the whole modern js toolchain (webpack...babel...extra compile times)

There's also a big difference for us within the form world between forms with ephemeral state and forms that need to persist state through many interactions and sessions. The former is perfectly fine for us to handle with vanilla js, the latter just becomes easier for developers with a declarative model.

Re: Stimulus.js 2.0

#136

Post by porker »

catwind7 wrote: post #119
porker wrote: post #91

Earlier quoted context omitted.

Awesome answer. I work a lot on business systems with complex forms and agree with everything you say. We are still feeling our way for a solution as we don't want to move to a SPA (swapping one set of costs for another) but have outgrown our current SSR + hand-rolled JS + jQuery + Bootstrap JS mess.

I still have reservations about moving too heavily towards an SPA - we still mostly have server-side rendered pages that render with react components so we don't have to deal with things like client side routing. It's also still important for us we render most of the page server-side for performance reasons, but I'm not too informed about the specific trade-offs there in load times if we did push more rendering to th…

> There's some companies already in that space though, so I might take some time to check out some existing solutions and see if there's some kind of needs gap.

Which companies are you thinking of? It's been too long since I looked beyond $dayjob and investigated what could be possible.

Re: Stimulus.js 2.0

#137

Post by sph »

davidjnelson wrote: post #132
cercatrova wrote: post #129

Earlier quoted context omitted.

Works fine, the NodeJS server simply builds the React page, nothing more. The API does all the heavy lifting of course.

yup, and if you want to really optimize it you could use functions as a service like lambda as your react rendering layer, which forwards to heroku or fargate or beanstalk or vanilla ec2 or whatever for your backend. and if cloudflare workers ever support metered usage you could use that too for the react layer. and if you want hyper performance you could use lambda@edge and intelligently route to your backend runnin…

This sounds like madness. Not cost effective to deploy, nor cost effective at all to implement in the first place. It's literally setting money on fire.

What's the equivalent of Poe's law, but for software development?

Re: Stimulus.js 2.0

#138

Post by catwind7 »

porker wrote: post #136
catwind7 wrote: post #119

Earlier quoted context omitted.

I still have reservations about moving too heavily towards an SPA - we still mostly have server-side rendered pages that render with react components so we don't have to deal with things like client side routing. It's also still important for us we render most of the page server-side for performance reasons, but I'm not too informed about the specific trade-offs there in load times if we did push more rendering to th…

> There's some companies already in that space though, so I might take some time to check out some existing solutions and see if there's some kind of needs gap. Which companies are you thinking of? It's been too long since I looked beyond $dayjob and investigated what could be possible.

https://formium.io/ is the company behind react's popular formik library

Re: Stimulus.js 2.0

#139

Post by phaedryx »

andrei_says_ wrote: post #95
phaedryx wrote: post #58

I worked with Stimulus for about a month and found it to be frustrating: 1. There is not a lot of documentation 2. They don't provide any testing guidelines, the best I've found is hand-wavy test-with-a-browser stuff 3. Everything is essentially global 4. Functions are disconnected from their parameters, i.e. I can't tell which bits of data a function is using without digging through a bunch of code. 5. Putting state…

Doesn’t vuejs require you to keep your state in a store object (data: {}) and render html via js though?

No it is flexible and Vue 3 let's you do it more react-hooks style.

Re: Stimulus.js 2.0

#140

Post by arvindamirtaa »

sandebert wrote: post #23
tpetry wrote: post #9

Earlier quoted context omitted.

Htmx is more like all „we try to solve everything for you but fail“ solutions. The good part of stimulus is that it is only a binding library, no automatic content refetch etc. solution

How does htmx fail?

Seriously!

I've been following them since the intercooler days and they've been great (functionally) although maybe a little drowned out by all the SPA chatter. Still a great library IMO.

Post reply on HN