I am under the impression that we should be using the rails api and any of js framework in frontend to build new applications. Now that stimulus and viewcomponent is here what do you think can these be used instead? Is it worth learning and using? I want to know your thoughts on this
Of course. That is exactly why Hotwire is so interesting. Instead of building two different apps, not to mention all the challenges that come with that, you only build one.
I also have the same impression. Rails asset pipeline changes frequently and upgrading rails versions is a pain because of this. Using rails for apis only and using a frontend framework seems to use the best of both worlds
Thanks for the video! I like how you look both at what's good and what could be better. I'm curious why not just use partials to obtain the same benefits you mention (reusability, design system, etc.)?
It's possible to do that using partials. It's just that this library makes it a bit easier if you're willing to depend on a 3rd party library for that. But you should always think twice about using a library for such a big part of your app. History has proven that's often a bad idea. Personally, I like to stick to partials as much as possible.
@@mixandgo Thanks for sharing. That was exactly my thinking. I feel I've been down this path before with a 'clever' new approach that turns out to be more of a burden later.
I appreciate that you gave it a good in-depth look and worked to find the useful aspects. I just can't shake the feeling that this is pretty over-engineered even for what it *is* able to achieve. You mention that with some updates this might become more useful - what additions could you imagine to make this a good pickup?
I would love to see an easy way to isolate and/or incorporate all dependencies, so if for example you have a form that depends on a controller, or some non-global css. A gem (like devise) would be a close example. What I'm going for is, plug and play functionality. Forms are the first thing that comes to mind.
Man but is not a good idea create a lot of components wrapped in helpers, uf you create a lot of helpers your aplications run slow because helpers is loading in the initial time when start your aplication for this reason was creating concept as drapoer to create decorator and load in demand. What do you opinion?
Does it make sense for regular web apps? At first it makes sense, then you see the complexity of the code going uphill. viewcomponent is produce of react fanboys. They want to complicate everything possible in name of testability
![Blox Fruits Dragon Rework Update [Full Stream]](http://i.ytimg.com/vi/EqDAp8udhm0/mqdefault.jpg)
![Seungmin "그렇게, 천천히, 우리(As we are)" | [Stray Kids : SKZ-PLAYER]](http://i.ytimg.com/vi/kAzmhLHePqU/mqdefault.jpg)
Fantastic review. Really fair evaluation.
Thanks for watching Sebastian
thx for this video !
You bet!
Thanks for sharing.
Glad you liked it
What is that chrome extension that fill the form automatically? 🤔
chrome.google.com/webstore/detail/fake-filler/bnjjngeaknajbdcgpfkgnonkmififhfo
I am under the impression that we should be using the rails api and any of js framework in frontend to build new applications. Now that stimulus and viewcomponent is here what do you think can these be used instead? Is it worth learning and using? I want to know your thoughts on this
Of course. That is exactly why Hotwire is so interesting.
Instead of building two different apps, not to mention all the challenges that come with that, you only build one.
@@mixandgo thank you for the reply. I will be learning to work with hotwire and see what I have been missing.
I also have the same impression. Rails asset pipeline changes frequently and upgrading rails versions is a pain because of this. Using rails for apis only and using a frontend framework seems to use the best of both worlds
@@silencipher I disagree. To me, Hotwire is the way to go.
Thanks for the video! I like how you look both at what's good and what could be better. I'm curious why not just use partials to obtain the same benefits you mention (reusability, design system, etc.)?
It's possible to do that using partials. It's just that this library makes it a bit easier if you're willing to depend on a 3rd party library for that.
But you should always think twice about using a library for such a big part of your app. History has proven that's often a bad idea.
Personally, I like to stick to partials as much as possible.
@@mixandgo Thanks for sharing. That was exactly my thinking. I feel I've been down this path before with a 'clever' new approach that turns out to be more of a burden later.
@@dfriis yup, same here.
i just started learning rails
you have a misspelling on one of your links above, instead of 'mixandgo', you've for 'mxiandgo'..
Thank you Martin
I appreciate that you gave it a good in-depth look and worked to find the useful aspects. I just can't shake the feeling that this is pretty over-engineered even for what it *is* able to achieve. You mention that with some updates this might become more useful - what additions could you imagine to make this a good pickup?
I would love to see an easy way to isolate and/or incorporate all dependencies, so if for example you have a form that depends on a controller, or some non-global css.
A gem (like devise) would be a close example.
What I'm going for is, plug and play functionality. Forms are the first thing that comes to mind.
Man but is not a good idea create a lot of components wrapped in helpers, uf you create a lot of helpers your aplications run slow because helpers is loading in the initial time when start your aplication for this reason was creating concept as drapoer to create decorator and load in demand. What do you opinion?
I don't think that's the case... why do you say that?
reusable? ain't partial does that job?
Does it make sense for regular web apps?
At first it makes sense, then you see the complexity of the code going uphill.
viewcomponent is produce of react fanboys.
They want to complicate everything possible in name of testability
Just like Angular components but instead of type script Ruby is involved.
I don't think that's a fair comparison. Everything happens on the back-end here. There's no client-side logic at all (unless you add JS).
Right, it’s a component system for server side organisation/rendering, independent of how you might do your JavaScript or CSS.