search

julianrubisch / better-stimulus

An opinionated collection of StimulusJS best practices
https://www.betterstimulus.com
MIT License
260 stars 16 forks source link

Ultimate resource for a stimulus related content. #28

Open skatkov opened 4 years ago

skatkov commented 4 years ago

Hey @julianrubisch!

It would be great to have an ultimate one-stop resource for stimulus related content. Let have a discussion here, if we can make it happen by merging our efforts together.

There are couple of possibilities that we can discuss here:

pinging @leastbad

julianrubisch commented 4 years ago

great initiative! I feel we should get more people on the table though?

@excid3 @adrienpoly

skatkov commented 4 years ago

@julianrubisch Agreed! Added more details to initial post!

julianrubisch commented 4 years ago

it would be great to have a search function/registry for controllers, too... maybe with intelligent tagging etc... @hopsoft, @excid3 and @adrienpoly have written excellent reusable controllers and we should avoid too much duplication

skatkov commented 4 years ago

It sounds like a good idea, as long as it's powered by jekyll.

Talking about Jekyll and JAMstack, there is this website dedicated to "JAMstack eco-system" called https://www.thenewdynamic.org/ . It feels really similar to what we discuss here and they have an awesome community too :-P

julianrubisch commented 4 years ago

At this point I wouldn’t be too constrained about technology. The question is what do we want to offer to whom.

Stanislav (Stas) Katkov notifications@github.com schrieb am Mo. 1. Juni 2020 um 20:51:

It sounds like a good idea, as long as it's powered by jekyll.

Talking about Jekyll and JAMstack, there is this website dedicated to "JAMstack eco-system" called https://www.thenewdynamic.org/ . It feels really similar to what we discuss here and they have an awesome community too :-P

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/julianrubisch/better-stimulus/issues/28#issuecomment-637040900, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABBGRUB76QK2F4CCRISV4RDRUP2CTANCNFSM4NP7IIRA .

skatkov commented 4 years ago

As @leastbad said before: ".. And I wish that @skat's page was it, but he's hesitant to graduate it past GH pages when I've spoken with him about it."

My biggest concern is the longevity of a project -- if we have to cheap in for hosting or do "maintenance" work ... it will become a burden very fast. It's not as much about "money", but personal time.

I would stress out, that no matter what we do, it would be of great benefit to have a mostly static website that could be served over CDN (or github pages or netlify). The setup you have right now -- with service worker, jekyll and etc -- seems perfect. This is why I'd love to consider possibility to merge.

miatrinity commented 4 years ago

Hey guys - awesome idea!

I think the adoption of Stimulus (and in a broader sense, related technologies like Turbolinks, CableReady, Stimulus Reflex, Morphdom etc.) is greatly hindered by the lack of consistent documentation - and even the existing documentatino is all over the place. If I got a nickel every time I read someone bitching about NO usable material on ActionCable, for example, I'd be... well, not a millionaire, but could surely buy a gourmet meal or something :)

tl;dr: there's just scant/all-over-the-place documentation for these technologies - some are better than others (Stimulus Reflex being by far the best, I'd say it's actually great - documentation, tutorial examples - a one-stop-shop if you want to learn SR).

But even then, it's difficult to understand how does SR fit in the picture, or even 'what IS the picture'. Why should you use these tools over say, Rails API+React? Which of the tools exactly? Which one does what and how to they work together? Were can you resources (tutorials, best practices, examples etc.)?

We are hoping to rectify the situation by creating a series of long-form articles, catering mainly to experienced Rails devs who are good on the backend, but not so much on the frontend, and just get swayed by everyone pushing them in the 'React is hot' direction even before they'd had a chance to evaluate the FE stack we are talking about here.

Or maybe they wanted to evaluate it, but as I said, the info was so scattered all-over that they just gave up and went with React/Vue, or maybe even Express or some other backend (I personally think that the fact that Vue is baked into Laravel makes a huge difference in adoption. BUT, it's documented well - so even though Stimulus+Turbolinks is baked into Rails , the adoption is nowhere near to Laravel+Vue, because of the lack of documentation/endorsement from the core team).

Because we are currently waiting on Basecamp to release the next big thing™️, it's maybe not the best time to launch such a series, but I think it's still better to have something that can be updated than waiting indefinitely.

Here's the rough outline of what we have been thinking - please let us know if we are missing anything etc.

Modern Rails View Layer - Edition 202x

Let us know what do you think. Does this make sense? If not, why not? Should we wait on DHH's announcement? What are we missing? etc.

skatkov commented 4 years ago

It seems, that there is more than enough of "introductions" to this technology, but not as much in-deep content or actual examples from battle tested projects. I'd personally would love to see more how this stack benefited you in your indie maker journey (since I'm trying to be one myself :P) with moaaar examples of actual code.

You can also spin off content if DHH will make any crucial changes.

adrienpoly commented 4 years ago

Hey some quick feedback

1) I really like better stimulus concept as it is now. It is quick and easy to read and makes an excellent complement to the official handbook for more advanced pattern.

2) The Awesome list is a great source of curated content but as ALL awesome list (this might be my personal feeling), as it grows it ends up being a long list of links and it is not always very easy to find relevant content (Googling might end up being faster).

3) A newsletter would be great. I personally would have hard time finding content for a weekly NL. Monthly seems more realistic to me.

I see several need that could enhance this single resource point :

my 2 cents

julianrubisch commented 4 years ago

Thanks @adrienpoly, those are approximately my thoughts, too.

Pulling off something like railsbytes could be easily done with a jumpstart license (which I own), but of course it’d benefit greatly from the experiences made by @excid3 😁

miatrinity commented 4 years ago

Okay, obviously my comment was misplaced. I didn't quite understand what are you trying to achieve here (that's probably mutual, because I didn't manage to express myself correctly either). Way to go! #not

Either way, I'm out, sorry for the noise - nothing to see here, move on please 😅🙏🏾

leastbad commented 4 years ago

Hey everyone! I'm super thrilled that everyone jumped on this issue. I love that it's an issue - it means it's something we can take seriously, we can escalate, and some day, maybe even close.

There's lots of ideas and sub-discussions presented here that are excellent - for example, I've spent a lot of time thinking about distributing and installing controllers before ultimately throwing in with publishing an npm package - but I think we win faster if we keep this somewhat constrained to what we are prepared to bring to the world.

Here are the three things top of mind for me.

  1. We're all time constrained, but that said, I am on sabbatical and don't have kids - I actually do have some time, especially if I'm motivated and not dealing with crippling depression. I depart from @skatkov's suggestion of a static site because I actually believe that a minimally dynamic site that can support a simple workflow is actually easier to manage than merging pull requests. So I am willing to do some initial heavy lifting to get something exciting off the ground, and while we've all heard the joke about the engineers that looked at the pros+cons of the 12 competing power plug standards in use around the world and created a near-perfect 13th power plug standard... I have registered stimulusconnect.com for this initiative. The reason being that it's an awesome name, and it's one fewer decision we now need to make. 👼 (In truth, if a better idea comes up, I won't cry, but having wasted many hours naming bands and startups... you're welcome?)

  2. While I agree that content will initially be sparse for a weekly newsletter, I'd like to approach Peter Cooper sooner than later about piping our content into a semi-regular publication. With Stimulus 2/TL6/Hey/this initiative coming together, it's both the perfect time to get the conversation started and in my experience, there's no point in building this initiative if we're not planning for success.

  3. Saving the best for last, hopefully. I've read all of the comments above and what I would like to see stimulusconnect become is similar to what RubyInside and Ajaxian used to be, which is a combination newsfeed + search engine. People create accounts or use social logins to suggest new content via a simple form and also to like things. There's a hopefully growing list of moderators that can approve content. Finally, there would be a few static pages that list learning resources, link to videos.

I recognize that I'm taking a leadership baton and preparing to run with it. My goal here is to inspire action, not install autocracy - I will burn out as @skatkov warns if we're not all on the same page about what our goals should be. Really, I've just been woken up to the fact that "if not us, then who" is already something we should take for granted. The Stimulus community is only as big as we make it, but if we do this, we can make it a lot bigger. But the emphasis in the last sentence is we. There isn't any other group of folks that's gonna do this.

DamnedScholar commented 4 years ago

A static site would make the most sense if this were just about a JS tool (like many others), but since the core of this group is based around SR, the same submission/curation pattern that PRs would involve could be instrumented with a Rails application that showcases how the library works. Tutorials that say, "Here's how you install this library and implement a Hello World-level feature," are a dime a dozen and not that impactful. If the article content is higher-level stuff (project postmortems, production examples, deep dives into component libraries) and the intro material says, "Look at this site. Look at how cool it is. Now look at its code to see how cool these libraries are," that would be more impactful than having yet another set of auto-compiled markdown files.

julianrubisch commented 4 years ago

Agreed. I think it’s an opportunity insofar as we can take our time and think about the best approach and wait until stimulus 2 launches, then take action