I have great hopes that Stimulus 2.0 and Ruby 3.0 will put Rails back in the spotlight as the sane alternative to SPA abuse. Ruby and Rails have some really talented people on their teams and there's something special about the Ruby language which makes it such a fertile environment for innovation. Only Clojure compares in this respect.
Stimulus.js 2.0
51–60 of 140 posts
Re: Stimulus.js 2.0
#52Re: Stimulus.js 2.0
#53If anyone is interested in “the magic” DHH is talking about, this is a fantastic resource: https://dev.to/borama/a-few-sneak-peeks-into-hey-com-technol...
Re: Stimulus.js 2.0
#54I have great hopes that Stimulus 2.0 and Ruby 3.0 will put Rails back in the spotlight as the sane alternative to SPA abuse. Ruby and Rails have some really talented people on their teams and there's something special about the Ruby language which makes it such a fertile environment for innovation. Only Clojure compares in this respect.
Rails is already the sane alternative. Any full stack framework is. DotNet, Laravel, Django, Rails...
If you think you need a JS framework to handle your UI, you've already lost, and you're doomed to reinventing wheels that these technologies have already perfected.
Re: Stimulus.js 2.0
#55What's the difference between Pjax and Turbolinks? Just a generic version of the same thing? Could Stimulus [Reflex] be hacked to work with Django or does it have strong ties to Rails?
Re: Stimulus.js 2.0
#56Earlier quoted context omitted.
> "PETAL stack" of Phoenix, Elixir, Tailwind, Alpine.js, and LiveView Oh, finally a hipster stack after my own heart. My initial stack used Web Components instead of Alpine.js, but after one year trying to make it work (using lit-element) I'm battered, bruised and I declare Web Components a failed piece of technology [1]. Alpine is interesting, but not powerful enough for my use case, which is encapsulating common UI…
React is great though, why not just use that?
React is great if all your frontend is React. Using it to create reusable components to sprinkle in your static HTML is overkill, and anyway it does not work with LiveView and LiveView is pretty cool.
IMO React has a good data model and solid foundation, but the whole ecosystem it's relying upon is bad. I'm not a fan.
Re: Stimulus.js 2.0
#57Earlier quoted context omitted.
> "PETAL stack" of Phoenix, Elixir, Tailwind, Alpine.js, and LiveView Oh, finally a hipster stack after my own heart. My initial stack used Web Components instead of Alpine.js, but after one year trying to make it work (using lit-element) I'm battered, bruised and I declare Web Components a failed piece of technology [1]. Alpine is interesting, but not powerful enough for my use case, which is encapsulating common UI…
Shadow dom is optional for web components, web components are still useful without it, so I hardly see how that could be a reason for "failed piece of technology". Also, did you try with pure JS ? no lit ? I just removed StencilJS from my component to go pure-JS and it turns out I really prefer it that way, maybe it would suit you too to do WC without any additional JS lib ?
lit-element is a very light wrapper on top of the native API. The problem isn't lit-element, the problem is the native API is not that good, not ergonomic, still incomplete and so far removed from the modern way of building reactive websites, i.e. view = render(state)
You need some abstraction on top of the native API, working directly with it is even more painful. The fact I'm using lit-element is because many WC libraries force shadom DOM upon you, and only some make it optional (Stencil is one of those few, but the TS requirement is a no-go for my use case)
Re: Stimulus.js 2.0
#58I 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 in your HTML is tricky if you also want to modify the DOM.
6. Their naming scheme is cumbersome, e.g. data-controller="using-a--sub-directory" and data-target="some--nested--target-has-a.function", that is, the fact that everything is location-in-your-code-file-structure based.
And a lot of other small things.
Ironically, using Stimulus convinced me to switch to Vue because I liked their value proposition of "Javascript sprinkles for your HTML", which Vue lets me do, but more intuitively.
Re: Stimulus.js 2.0
#59I have great hopes that Stimulus 2.0 and Ruby 3.0 will put Rails back in the spotlight as the sane alternative to SPA abuse. Ruby and Rails have some really talented people on their teams and there's something special about the Ruby language which makes it such a fertile environment for innovation. Only Clojure compares in this respect.
Rails is already the sane alternative. Any full stack framework is. DotNet, Laravel, Django, Rails... If you think you need a JS framework to handle your UI, you've already lost, and you're doomed to reinventing wheels that these technologies have already perfected.
Isn't Stimilus a JS framework?
Re: Stimulus.js 2.0
#60Is there a convincing Stimulus vs. React-Rails post anywhere?
Or a convincing Stimulus vs. Vue post would be helpful too, since Vue is so simple to sprinkle in as well, and doesn't pollute the html with data attributes as much as Stimulus.
I switched from Stimulus to Vue and have had a much better experience so far. It is much easier for me to use and I still get the value of "sprinking"