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 (…
> the amount of boilerplate code which is generated is too high. Relative to what? From my experience other MVC web frameworks (e.g., Django, .NET, Laravel) have the usual fragmented directory structure typical of MVC + ORM. Unless you're comparing to other LiveView frameworks? In which case, Phoenix is still the OG, and more mature and capable vs other platforms.
Phoenix 1.7 is View-less
151–160 of 224 posts
Re: Phoenix 1.7 is View-less
#152Earlier quoted context omitted.
Honestly without proper editor support from a company like intelli-j, I just can't see myself picking it up. Hard to give up on the niceties it provides, especially when working on a non-static language I did try the third-party intelli-j plug-in but never got it to work If it had that... look out!
You are missing a lot of the best tech out there in the programming world if you are waiting for an IntelliJ-like IDE for each programming language.
What kind of best tech would you put in this category?
Re: Phoenix 1.7 is View-less
#153The main issue, is there's no demo !
Re: Phoenix 1.7 is View-less
#154Earlier quoted context omitted.
Heex and components are essentially one-in-the-same. Heex enabled components upon its release and now the framework is (rightfully) pushing components. Forms I agree with, though I don't feel that pain too badly. Having to be more explicit than just passing in raw parameters to an update function actually has its benefits (though I'm sure better forms are coming along). Agreed that the framework is moving faster than…
W.r.to boilerplate - I have no reference point/comparision to other frameworks. When the project grows with more contexts, components and forms, one will end up with a bunch files which differ only in Module.func_names. Phoenix < 1.7, View files which are required for controllers are boilerplate which contain 3-4 lines. In the end there will be a folder with view files which don't will have similar content unless any…
It seems like essential complexity to me. I think maybe there's some ceremony around explicitly casting, validating, etc. with Ecto, but it would be hard to hide that without 'magical' assumptions and making it more inflexible. But I agree View files always felt a little redundant for many use cases where the template doesn't really need to make any function calls – and from memory, function calls in LiveView templates is not performant and causes the whole DOM to be regenerated when values change.
Re: Phoenix 1.7 is View-less
#155Can someone _please_ get around to building a framework for Gleam[0] so that I can finally get over my hesitance to dive into a BEAM language over erlang's/elixir's dynamic typing? [0] https://gleam.run/cheatsheets/gleam-for-rust-users/
Remember, he who types statically types twice the amount and thus half as fast. There's honestly no need for static typing in Elixir.
> he who types statically types twice the amount and thus half as fast.
If you mean by this, "static typing is not worth the effort", the zeitgeist is definitely not with you on this one.
> There's honestly no need for static typing in Elixir.
I'd love for that to to be the case! Is the only way for me to find out for me to give it a try, or are there somethings you can say to help me believe?
Re: Phoenix 1.7 is View-less
#156Can someone _please_ get around to building a framework for Gleam[0] so that I can finally get over my hesitance to dive into a BEAM language over erlang's/elixir's dynamic typing? [0] https://gleam.run/cheatsheets/gleam-for-rust-users/
I think if you actually try elixir you will find its lack of typing to be of little concern.
Gotcha. Appreciate the encouragement!
Re: Phoenix 1.7 is View-less
#157Can someone _please_ get around to building a framework for Gleam[0] so that I can finally get over my hesitance to dive into a BEAM language over erlang's/elixir's dynamic typing? [0] https://gleam.run/cheatsheets/gleam-for-rust-users/
You can use gleam in an application that uses Phoenix for web plumbing pretty easily.
Good to know!
Re: Phoenix 1.7 is View-less
#158Earlier quoted context omitted.
Has anyone figured out how to do static typing in Erlang yet? FB a few years ago announced they were going to work on it for WhatsApp but then it was indefinitely delayed. There’s also been a few other attempt, but I don’t believe anyone has succeeded. I know Gleam exists but haven’t dug into it. Anyone more in the know care to share?
Jose has been working with some PhDs to attempt to implement static typing https://elixir-lang.org/blog/2022/10/05/my-future-with-elixi... In the meantime I don’t know what people have against using @spec. It’s a far more powerful type specification than the majority of static-typed languages out there
> In the meantime I don’t know what people have against using @spec.
It's not ergonomic enough (you end up writing function definitions twice).
And there's very little tooling to help automate the process: if you return the result of a function call, good luck figuring out the spec for that if that function is in a library somewhere
Re: Phoenix 1.7 is View-less
#159Earlier quoted context omitted.
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.
Based on the number of attempts to add static typing to Erlang, I don't see this ever happening. I know the author of Gleam is going full-time working on it, but I really know much about it or how it gets around the problems with statically typing message-passing. I'm perfectly happy working in dynamic languages and find Elixir's type hinting to be more than adequate.
While it's not as robust as static-typing, compile-time type checking for Erlang has come a long way. Eqwalizer works pretty well, though but I may be biased since my employer sponsors the project.
Re: Phoenix 1.7 is View-less
#160Hex Docs for Phoenix.View mention the change: https://hexdocs.pm/phoenix_view/Phoenix.View.html#module-mig... Phoenix.View is replaced by Phoenix.Component: > With Phoenix.LiveView, Phoenix.View has been replaced by Phoenix.Component. Phoenix.Component is capable of embedding templates on disk as functions components, using the embed_templates function. More on hexdocs.
I was going to come here and link directly to this - the migration from previous versions is always covered in detail and seems to always work which is great. A lot of frameworks seem to struggle with this quality of documentation when upgrading versions.