surface
stimulus_reflex
Our great sponsors
surface | stimulus_reflex | |
---|---|---|
11 | 45 | |
1,982 | 2,186 | |
1.3% | 0.8% | |
7.8 | 7.5 | |
6 days ago | 17 days ago | |
Elixir | Ruby | |
MIT License | MIT License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
surface
-
htmlgui.nvim - Create html + css + lua apps with neovim as 'browser'. ( proof of concept )
I should have been more clear that my intent was to create/use a compiler for some kind of component syntax. There are lots of them, from Surface (Elixir), Blade (PHP/Laravel), and JSX (React, Vue, Etc)
- Would you still choose Elixir/Phoenix/LiveView if scaling and performance weren’t an issue to solve for?
-
Why I selected Elixir and Phoenix as my main stack
There I learned more deeply about LiveView and Surface UI.
-
Something similar to Vuetify for Phoenix LiveView?
I think Surface is the ideal candidate for this. But it doesn’t have the components you are looking for but you can build anything with it. Hopefully, in future we can have set of headless components built using Surface 🤞
-
Course/Extensive tutorials for Phoenix 1.6?
This is just an idea, but what about implementing using Phoenix.View(via use MyAppWeb, :view in your module)? Then assign I think has access to @conn. Then maybe work some magic to still allow Phoenix.Component syntax - but at this point, this is something I believe is a flow that might be in development. Try investigating / asking in Surface, because that is a lot more similar to React in its approach. In fact, I think Surface is where more aggressive features are pushed out, and ironed-out features get included into Phoenix. This was the case for Phoenix.Component, and HEEX.
-
We Got to LiveView
I totally get the "Am I doing this the right way?" feeling, especially coming from Rails where everything was so opinionated and wanting to stay idiomatic.
Phoenix, while it does have opinions, is far less opinionated in the sense that it doesn't do it darndest to force you into certain conventions (for example, if your module name doesn't match your file name, Phoenix won't complain). Its generators do try and push you toward using good DDD practices (which is my opinion is a GREAT thing), but of course the generators are completely optional.
I don't have experience writing large LiveView apps but I would say that if you are familiar with any component-based frameworks (like React), I would take a look at SurfaceUI[1]. It simplifies a few "gotchas" in LiveView (though I would say they are very minor gotchas and worth learning about at some point) and gives you a component-rendering syntax more like React. Once you get going, you'll learn that LiveView doesn't have all the headaches that come with bigger React apps (like having to memoize functions or comparing props to avoid a re-render and whatnot). The recent release candidate for Phoenix 1.6 has made strides for a cleaner component syntax, but if you're having trouble with LiveView, Surface might bring some familiarity.
-
Phoenix 1.6.0-RC.0 Released
Have you seen Surface UI? Pretty cool. Collection of LiveView components. https://surface-ui.org/
-
Letter Square: Post Mortem
I also did not use "vanilla" LiveView, as I used the Surface library. This is a wrapper around LiveView that brings a whole new syntax to make the experience even more comfortable.
stimulus_reflex
-
Coming to grips with JS: a Rubyist's deep dive
Then there are stack-specific libraries: StimulusReflex for Rails, Phoenix LiveView, Laravel Livewire, Unicorn and Tetra for Django, Blazor for .NET, … and the list goes on.
- Почему я программирую на Ruby
-
RailsWorld 2023: Hotwire Edition
Morphing and the concept to do refreshes after broadcast are hardly new. Stimulus Reflex has employed morphing to update the page for years, and CableReady::Updatable, which allows listening to model requests for refreshes, has also been around for a while. But I am excited to see these concepts being adopted in Turbo and becoming more mainstream.
-
Unicorn – A full-stack web framework for Django
Stimulus Reflex (Ruby), which predates Hotwire, also deserves a mention, though most of its momentum seemed to stall when Hotwire was announced.
-
Is there Ruby LiveView Framework?
Hi there, not crazy experienced on the topic but after some research i made for personal reasons i found https://mayu.live/ whick looks interesting (and as mentioned already https://docs.stimulusreflex.com/, seems to be close to Liveview)
-
Rails 7 - Turbo Frame and Turbo Stream
StimulusReflex Docs pretty easy to use and release 3.5.0 is coming soon.
-
Announcing elm-express
However, the timing may be a little off. In some ways, it feels like the "Express" way of developing for the backend is dying. We are seeing tools that blur the line between backend and frontend, trying to unify how we develop web applications. Tools like Phoenix LiveView, StimulusReflex, Laravel Livewire, Remix, Next.js, and many others are being developed.
-
A powerful search feature with what Rails provides out of the box
Reading the article and the source code, I learned a ton of stuff, as always. In his implementation, Louis is using StimulusReflex (built on top of Stimulus) to achieve this. I was curious about several points:
-
The Ultimate Search for Rails - Episode 1
First things first: on the frontend, we’ll use StimulusReflex (a.k.a SR) to build a super reactive and friendly search experience with very little code, and little to no JavaScript. For those unfamiliar:
Now that we know that our backend is working as it should, let’s wire up our stuff. I’m gonna skip on Stimulus Reflex setup and configuration and dive right in. You can easily follow the official setup or, if you use import-maps, follow @julianrubisch’s article on the topic. I also know that leastbad has been working on an automatic installer that detects your configuration and sets everything up for you if you care to try it before the next version of SR gets released.
What are some alternatives?
hotwire-rails - Use Hotwire in your Ruby on Rails app
turbo - The speed of a single-page web application without having to write any JavaScript
jsbundling-rails - Bundle and transpile JavaScript in Rails with esbuild, rollup.js, or Webpack.
react_phoenix - Make rendering React.js components in Phoenix easy
hotwire-livereload - Live reload gem for Hotwire Rails apps.
torch - A rapid admin generator for Elixir & Phoenix
Stimulus - A modest JavaScript framework for the HTML you already have
phx_component_helpers - Extensible Phoenix liveview components, without boilerplate
webtransport - WebTransport is a web API for flexible data transport
Mercure - 🪽 An open, easy, fast, reliable and battery-efficient solution for real-time communications
phoenix_live_view - Rich, real-time user experiences with server-rendered HTML
Raxx - Interface for HTTP webservers, frameworks and clients