surface
Alpine.js
Our great sponsors
surface | Alpine.js | |
---|---|---|
11 | 242 | |
1,990 | 26,798 | |
1.6% | 1.8% | |
7.8 | 9.3 | |
15 days ago | 3 days ago | |
Elixir | HTML | |
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 🤞
-
Single source of truth with Phoenix LiveView
I have worked with Phoenix LiveView and Surface-UI for about a year; I would like to share some of the things I learned the hard way.
-
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.
-
Porting files generated by phoenix to surface
This post is intended to get you started with surface provided components. I provided the original code and surface versions so you can compare the differences yourself without installing anything. After installing surface following the installation guide https://surface-ui.org/getting_started add surface_bulma in your mix.exs, this will allow you to use the table component.
-
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.
[1] https://github.com/surface-ui/surface
-
Phoenix 1.6.0-RC.0 Released
Have you seen Surface UI? Pretty cool. Collection of LiveView components. https://surface-ui.org/
- Surface UI – A server-side rendering component library for Phoenix
Alpine.js
-
Biometric authentication with Passkeys
Alpine.js for reactive frontend
-
🤓 My top 3 Go packages that I wish I'd known about earlier
✨ In recent months, I have been developing web projects using GOTTHA stack: Go + Templ + Tailwind CSS + htmx + Alpine.js. As soon as I'm ready to talk about all the subtleties and pitfalls, I'll post it on my social networks.
-
Htmx Is Composable?
> But honestly, torn towards htmx but undecided.
We are in the middle of migrating from our monster react application into server rendered pages (with jinja2). The velocity at which we are able to ship and the reduction of complexity has been great so far.
Managing client side state for simple things like (is the dropdown open/closed), listening to keyboard events and such can be done with something like alpine-js [1] without all the baggage that something like react brings.
It appears this is already the trend with JS frameworks too - with server side rendering being the new norm.
[1] https://alpinejs.dev/
- Pocketbase: Open-source back end in 1 file
-
Coming to grips with JS: a Rubyist's deep dive
Sure, you can use any number of JS-avoidance libraries. I'm a fan of Turbo, and there's also htmx, Unpoly, Alpine, hyperscript, swup, barba.js, and probably others.
-
What is your opinion about developers who do direct DOM manipulations instead of using modern web frameworks (like React, Vue, Angular) to achieve maximum performance?
Direct DOM, but with a library. Specifically AlpineJS since it follows Vue closely in design practices allowing me to scale into a full web application if necessary (basically swapping to Vue takes minimal work). The Morph plugin is specifically what I like using.
-
Kicking the tires with NestJS and Hotwire: Part II
If you want more details on the initial setup I encourage you to take a look at the Part I that covers more of the initial implementation. For this portion, I added Prisma as an ORM, a frontend style library called Tachyons, and AlpineJS to handle any client-side interactions. I did this to avoid needing to add a client-side bundler to the build and instead just rely on plain old module imports to compose the frontend. This is now the default for Rails and it is quite nice to not need any additional build tools for the client.
-
Deveplop a simple GUI app by Wails use Golang
- [swallow-pywebview](https://github.com/rangwea/swallow-pywebview): Base on [pywebview](https://pywebview.flowrl.com/) using Python,the frontend base on [alpinejs](https://alpinejs.dev/) and [tailwindcss](https://tailwindcss.com/)。
-
How to Make an Animated Number Counter with Tailwind CSS
If you’ve followed our other tutorials, you might be familiar with Alpine.js. It’s a lightweight JavaScript library that allows you to add interactivity to your site without writing a single line of JavaScript. It’s incredibly easy to use, and we’ll show you how to make the animation trigger when the user scrolls to it.
-
A First Look at HTMX and How it Compares to React
The approach is not new, essentially a variation of Knockout, Alpine, and similar "JS-in-HTML" approaches.
What are some alternatives?
react_phoenix - Make rendering React.js components in Phoenix easy
Svelte - Cybernetically enhanced web apps
torch - A rapid admin generator for Elixir & Phoenix
petite-vue - 6kb subset of Vue optimized for progressive enhancement
phx_component_helpers - Extensible Phoenix liveview components, without boilerplate
htmx - </> htmx - high power tools for HTML
phoenix_live_view - Rich, real-time user experiences with server-rendered HTML
React - The library for web and native user interfaces.
Raxx - Interface for HTTP webservers, frameworks and clients
Stimulus - A modest JavaScript framework for the HTML you already have [Moved to: https://github.com/hotwired/stimulus]
plug - Compose web applications with functions
hyperscript - Create HyperText with JavaScript.