In this case I don't see how regular functions would do. It's a way of giving a module specific behavior in a way that fits in with the application structure Phoenix enforces. That aspect of it is very Railsy, but the way it's implemented is totally different. Elixir macros are much closer to Lisp macros than Ruby macros, because they are not object oriented. I personally find them much easier to read and understand as a result. Here's __using__ in Phoenix.LiveView: https://github.com/phoenixframework/phoenix_live_view/blob/v...
I think LiveView is a very compelling technology and I'm not sure we would have it if Elixir didn't exist, because Elixir brought a whole raft of different perspectives into the Erlang community. Erlang and Elixir are about as close as two languages can get, and I find complaints from either camp about the other silly. It reminds me of Python vs Ruby flame wars.
Maybe it's just because I'm used to C# and F# and the way they feel in the .NET world, but Elixir and Erlang both feel like different syntaxes over the exact same underlying language concepts.
I agree that Elixir macros are far easier to understand than Ruby macros since they are defined at compile time rather than runtime.
But I am against reaching for macros when the same can be accomplished using the basics: modules, functions, structs. I've seen various instances where a macro doesn't add much expressiveness over the plain old functional approach.
Granted there are many areas where macros are very powerful. Ecto is a perfect example of when macros make sense. Adds a lot of expressiveness to build queries which is worth the cost of macros.
Also should note that I love Elixir. We are using it in production to power all of our backend systems :)
To add a data point: Ruby and Elixir developer here (and Python and JS). I never wrote a macro in Elixir. All that weird quote / unquote stuff is too complicated. I get the idea (code running at compile time) but the syntax is just unwelcoming. Furthermore macros tend to make code opaque and onboarding difficult. I could wake in terror if I dream of my coworkers implementing some new functionality by adding macros instead of functions.
Agreed. My approach is to use macros written by someone smarter than me (Ecto), but refrain from writing macros myself. Regular functions very often are enough.
Macros are definitely abused, but there are some cases, fewer than you think, where they make code easier to follow.
: ) Don't get me started on LiveView, i was only talking about mimicking rails mixins with the "use" macro in phoenix.
But now that you ask: The LiveView Idea to use websockets in general purpose web applications to achieve "reactivity" is an abomination, we have SSE and HTTP2 and also SPAs for that matter, which are from an operational and reasoning standpoint 1000% simpler and actually made for this kind of thing.
Websockets are for things like multiplayer shooters or collaborative drawing, why would someone think it is appropriate to use it to react to clicking a button.
So what should Phoenix use instead of a using macro to accomplish this?
>But now that you ask: The LiveView Idea to use websockets in general purpose web applications to achieve "reactivity" is an abomination, we have SSE and HTTP2 and also SPAs for that matter, which are from an operational and reasoning standpoint 1000% simpler and actually made for this kind of thing.
SPAs are hugely complicated though. Have you worked on a production React app? It's another order of complexity above anything existing in BEAM world, and the JavaScript tooling ecosystem is atrocious in comparison. Not to mention, you will quickly end up having button clicks that require network requests if you are not careful with your SPAs as well.
The whole point of LiveView is that you can develop an app with a similar amount of interactivity as a React app without having to go into the split-universe world that SPAs live in and all the attendant complexity that brings with it.
>Websockets are for things like multiplayer shooters or collaborative drawing, why would someone think it is appropriate to use it to react to clicking a button.
People said JavaScript was just for making ad banners flash 20 years ago and now it's the most popular language on the planet. I don't think a technology's current uses are a good predictor of what it is most useful for. See also: the web itself becoming an application platform, while it started off as a hyperlinked document retrieval system.
With respect, web sockets are a tool. If you think it is inappropriate to use a tool a certain way then your are obviously free to feel that way, but it seems a little “get off my lawn” to be upset with other folks finding creative uses for it.
My team is using live view and accomplishing incredible things with far less time and effort than we would need using other SPA technologies.
I have no idea how you can assert SSE, HTTP2 and SPAs are 1000% simpler when my experience over the last two years has been the exact opposite. Live view is exceedingly simple to work with.
