[blueblahvlah]

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 (no backward compatibility).

- the amount of boilerplate code which is generated is too high.

- forms are basic and need to evolve for handling challenges which come with Server side rendering and interactivity

- there was leex, then heex, now components taking centre stage.

- most of the books, tutorials, videos, articles are stale due to frequent changes / evolution

Elixir/Phoenix Community is small and non toxic on forums. But sometimes the size of community is drawback. Some questions get fewer replies and will be a puzzle for the developer who is working on the project (this does not happen frequently).

Anyone who wants to adopt Live View for production projects will have to overcome these challenges.

(edits: formatting)

[josevalim]

> - 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.x exactly because it is still backwards compatible (and it has been so for 7.5 years!).

The last steps before LiveView v1.0 are likely forms (which you mentioned) and perhaps a better mechanism to stream with appending/prepending/replacing data.

Once it is out, we hope the remaining cons will be quickly addressed, except the boilerplate bits. The boilerplate is always a trade-off: if we hide too much, then the pieces become more coupled and it is harder to understand how they fit together. So I’d say Phoenix strikes the right balance here and if you have a highly formulaic application, projects like Ash may be to your taste. :)

[conradfr]

All web frameworks fail with forms one way or the other :)

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).

[0] https://github.com/conradfr/FunkyABX

[hartator]

> 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.

[josevalim]

That’s one aspect. But I would say the fact that existing Phoenix apps can migrate to v1.7 and use other features such as verified routes without going through a major migration is an important aspect that should not be downplayed, especially when other frameworks may have gone through more than one major version in those 7.5 years and broke existing code more than once.

[sodapopcan]

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 the available literature on it, though people are doing their best and are doing a pretty good job of keeping up.

What is it about the boilerplate that annoys you? It's quite a bit less than Rails, though that's my only point of comparison unless you're going to unfairly compare it to a microframework. There aren't any generated files that I'm not thankful I can easily edit if I need to.

[blueblahvlah]

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 view specific functions are added.

[h0l0cube]

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.

[preciz]

I'm working on a medium sized LiveView project now.

The leex to heex change was 1 day for us and the benefits were immediately worth it. (HTML auto formatting and validation, better syntax). Components were a thing before heex, I wouldn't say they are taking center stage now, there is no rewrite required there, you either use Component, LiveComponent or LiveView. When to use which is very simple as the their name indicate.

[blueblahvlah]

https://github.com/phoenixframework/phoenix/issues/4975

[preciz]

Thanks for linking this, we use LiveViews, we have only a few controllers.

[sb8244]

I'm hoping to see more patterns in the forms space. I spent 18 months building a product in LiveView (didn't work out in the end) and complex forms were one of the most difficult things.

I got really good at creating them in the end, but it was all homegrown patterns that I don't think I'd want to push on others.

My favorite (and fairly simple) pattern was emitting an event from server to client to get the client to send it's entire form state to the server. That was my escape hatch because it worked inside of any component structure.

[pbowyer]

What kind of forms were you creating? How to handle forms ergonomically has been a central interest of mine since 2003 and I like hearing about what people try and how it works for them.

[sb8244]

Ranging from very basic static form to forms that had dynamic /polymorphic embedded objects in them. Like being able to hit a + button and a new row is added as a child of the form that has it's own validations based on a type attribute.

[NhanH]

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 productivity. I am not sure why Phoenix did the same things without a clear path forward.

[josevalim]

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 requirements. At the same time, there is nothing stopping anyone using it on their Phoenix apps if they so desire.

[NhanH]

Is the plan to keep esbuild (and npm integration) for the long term, or would that be deprecated in a few years?

[josevalim]

I would hope it to be long term but it is impossible to know given how fast the JS landscape can change.

But also keep in mind that Phoenix is not tied to any of these. The esbuild bits are only part of the generated app, which you can stick to or change altogether.

So when we moved to esbuild, we broke zero of the existing apps and no deprecations were emitted. The same would happen if we move away from esbuild.

As an example, I moved most of my apps to esbuild (and I have been very happy with it), but one still uses webpack because it uses the Monaco editor and we rely on certain plugins. So our approach has always been “sane defaults” but not getting in the way if you know better or prefer something else.

[wstuartcl]

Snorted a little at this -- how can anyone forecast JS ecosystem 5 years out. =)

[blueblahvlah]

In my original post:

- there was leex, then heex, now components taking centre stage.

- most of the books, tutorials, videos, articles are stale due to frequent changes / evolution

Last two points should have been one. Got split while composing the post. My mistake.

- there was leex, then heex, now components taking centre stage. most of the books, tutorials, videos, articles are stale due to frequent changes / evolution

I am OK with evolution. From project maintainance and developer - its a challenge to keep up with things coming their way.

[wstuartcl]

regarding frequent changes, in my experience keeping 5 or 6 Phoenix/Liveview apps up to date the pain I have seen with changes is far less than I have experienced with Rails, Django and even front end updates required to keep react and vue inline. All of that when Liveview is not even a 1.0 yet...

I do get that books and other rotting materials obviously fall behind quickly but have you seen hard uplifts to codebases to keep them up to date?

[h0l0cube]

> 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.

[blueblahvlah]

https://news.ycombinator.com/reply?id=34193789&goto=item%3Fi...

[fud101]

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.

[josevalim]

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...

[fud101]

It comes down to whether you want to maintain a bunch of auto generated files which will never be automatically updated. I would rather maintain only the lines of code I write not ones that were generated by some tool and then immediately became legacy.

[dugmartin]

You beat me to the submit button by a minute.

[Existenceblinks]

I understand that generator is for education purpose. New comers might find it's cumbersome to get start if generators are absent. However, I think it should be just some guide docs. Generated context can mislead the concept of how to use the context itself. It's easy to quickly write a dirty API in phoenix, but practice guides lead to ceremony.

[dugmartin]

To be fair you could use Plug and Plug.Router directly and get almost the same line count as a flask app.

https://hexdocs.pm/plug/Plug.Router.html

[treadmill]

> Elixir/Phoenix Community is small and non toxic on forums

Golang taught me to appreciate this when choosing a language. The tone of the community made me look elsewhere.

The Elixir community is indeed very friendly and helpful!

[Existenceblinks]

- Engineering culture

As oppose to php, ruby, javascript culture which is; make/build/ship stuff to the world. IMO, this is the growth stopper. I couldn't care less about sophisticated clean architecture, module boundary, nice pooling http clients, principle goodness. The second growth stopper is jobs. Good luck finding future elixir developers if you do not help build the elixir army. Companies be like, lets choose birth control and adopts senior elixir devs instead.

[treadmill]

That... that is why you fail.

[Existenceblinks]

What I said is... true. (doesn't mean I don't appreciate status quo of ecosystem. Everything is good except it's not growing, probably side way up and down)