171–180 of 224 posts
Earlier quoted context omitted.
it takes like 6 lines of code to have a working flask endpoint to deploy a quick and dirty API. About a billion files for phoenix. I hate that too.
Phoenix by definition assumes your projects will take longer than an afternoon. :) If you want a quick and dirty API, using Plug directly may be an option: https://gist.github.com/josevalim/fbfc669aa6087c5b79402b399d...
View-less meaning Phoenix.View module is refactored/replaced. The amount of boilerplate code is still a challenge in Phoenix. Worked on a large project using live views. Pros: - can achieve interactivity without using client side js frameworks - less developers / man power needed compared to client side js frameworks - evolving in right direction - community / forums Cons: - still evolving and releases are breaking (…
> - still evolving and releases are breaking (no backward compatibility) To clarify, this is only true for LiveView which has not reached v1.0 yet. Even then, we have been careful with deprecations while exploring a new programming model with several new ideas. In fact, Phoenix v1.7 is precisely the consolidation of those ideas. I’d say Phoenix v1.7 would be tagged as v2.0 in most web frameworks, but we kept it as v1…
I think one point would be the docs, to outline the basic cases, best practices. Maybe something tying the form helpers and changeset together.
I have a side project [0] with a form which have inputs dependant of others and a dynamic section (assoc).
I struggled a bit with the data, checking what I would get inside a changeset struct, until I "discovered" get_field and put_change.
For the assoc I was also a bit lost until I read an article using a delete virtual field. In the end I made it work but I still not sure I used all the right changeset functions.
To LiveView credits this app has been used all over the world and got very good feedback, nobody mentioned any lag issue etc (well, someone with a crappy connexion in Istanbul once got an incomplete uploaded file without getting an error).
Elixir/Phoenix has hit full-stride. I feel like the next big unlock in user adoption is continued improvements to BeamAsm. Hopefully something on the order of 100-200% raw performance speed up. Note: I’m talking about raw perf, not concurrency. A few other additions to Phoenix 1.7 include: - verified routes - tailwind built in - additional web server support (bandit) https://www.phoenixframework.org/blog/phoenix-1.7-…
Actually, I think the next big unlock in user adoption is static typing. Lack of it is frequently cited as the number one reason that makes people hesitate in switching to Elixir. I know it is an active research project right now, and I hope it bears fruit.
The elixir project I was in had several dozen developers on it and specs were not enough. I always had to backtrack through several calls and/or run the code and dump the data and then capture the example data as a comment so future devs could know what was coming into the function. Not a great solution.
What is the Rails equivalent to Livewire? Actioncable? Hotwire? InertiaJs?
View-less meaning Phoenix.View module is refactored/replaced. The amount of boilerplate code is still a challenge in Phoenix. Worked on a large project using live views. Pros: - can achieve interactivity without using client side js frameworks - less developers / man power needed compared to client side js frameworks - evolving in right direction - community / forums Cons: - still evolving and releases are breaking (…
> - still evolving and releases are breaking (no backward compatibility) To clarify, this is only true for LiveView which has not reached v1.0 yet. Even then, we have been careful with deprecations while exploring a new programming model with several new ideas. In fact, Phoenix v1.7 is precisely the consolidation of those ideas. I’d say Phoenix v1.7 would be tagged as v2.0 in most web frameworks, but we kept it as v1…
I would say a big philosophical change like dropping Views is backward incompatible. You can’t use old tutorials now.
Earlier quoted context omitted.
> - still evolving and releases are breaking (no backward compatibility) To clarify, this is only true for LiveView which has not reached v1.0 yet. Even then, we have been careful with deprecations while exploring a new programming model with several new ideas. In fact, Phoenix v1.7 is precisely the consolidation of those ideas. I’d say Phoenix v1.7 would be tagged as v2.0 in most web frameworks, but we kept it as v1…
> but we kept it as v1.x exactly because it is still backwards compatible I would say a big philosophical change like dropping Views is backward incompatible. You can’t use old tutorials now.
Bruce Tate and Sophie DeBenedetto have been authoring the book “Programming Phoenix LiveView” (https://pragprog.com/titles/liveview/programming-phoenix-liv...) which has the potential to be a great source for people that want to really dive into LiveView. The challenge though is they have not updated it to support the changes introduced in 0.18.0 which makes it really hard to start using the book when a new Phoenix application “mix phx.new dev_app” looks different than what’s in their book and some of their code breaks with the default installed versions of included plugs.
While I wish the book would receive an update sooner that brings it back to a compatible state (meaning there are no issues following along with the book), the good news is they have committed to having the book be updated when LiveView hits 1.0.
LiveView is evolving into a great piece of tech, but as others have noted elsewhere in the comments one of the challenging parts with LiveView right now (and to an extent Phoenix) is the outdated books & tutorials. Bruce Tate and Sophie DeBenedetto have been authoring the book “Programming Phoenix LiveView” ( https://pragprog.com/titles/liveview/programming-phoenix-liv... ) which has the potential to be a great sourc…
[edit] I like the Project Status section of bandit - https://github.com/mtrudel/bandit#project-status
Earlier quoted context omitted.
Another thing I am concerned about is the removal of default integration with FE build pipeline and npm libraries. I understand the complexity of the pipeline, and Rails is doing the same. But the difference is that Rails has a replacement in place (importmap), while Phoenix recommends vendoring the lib. In additional, Rails has suitable replacement for the use case (hotwire) and a clear focus on the philosophy of pr…
The integration is still there and it is mentioned in our assets guide: https://hexdocs.pm/phoenix/asset_management.html#third-party... Regarding import maps, I am still slightly skeptical. First they don’t solve all needs of npm (for example, what if you need to precompile your FE code?). Second, I have feeling that every import map management tool will eventually become a package manager through slowly creep in of…