Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Phoenix 1.7 is View-less

germanvelasco.com

Post reply on HN
Print view View original

161–170 of 224 posts

Re: Phoenix 1.7 is View-less

#161

Post by fud101 »

h0l0cube wrote: post #149
blueblahvlah wrote: post #128

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.

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.

Re: Phoenix 1.7 is View-less

#162

Post by [deleted] »

sb8244 wrote: post #130
blueblahvlah wrote: post #128

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 (…

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…

[deleted]

Re: Phoenix 1.7 is View-less

#163

Post by Existenceblinks »

fud101 wrote: post #161
h0l0cube wrote: post #149

Earlier quoted context omitted.

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

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.

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.

Re: Phoenix 1.7 is View-less

#164

Post by conradfr »

sb8244 wrote: post #131
conradfr wrote: post #68

Earlier quoted context omitted.

But you don't get type checking as part of the build right?

Correct. You could rig something up in probably 2-3 days if that was super important for you. I did manual typing at the edges and that sufficed for me.

Well yes, not sure why I got downvoted, if I use a language called TypeScript it may be because I think type checking is important.

Having to call tsc separately from my dev/watch process is not a good developer experience. Same as with ... dialyzer :)

But for sure, that would decimate esbuild performances.

Re: Phoenix 1.7 is View-less

#165

Post by jspash »

dmix wrote: post #79
travisgriggs wrote: post #61

Earlier quoted context omitted.

For me personally, this is not the case. I work in multiple languages, some static, some not. And I have as many bugs in the one as the other. I add strings to numbers less in static ones, but I tend to make more design mistakes, because I have to steer through the constraints of the type system. I view "must have static types/compile time checking" types as a bit reductionist. It's like saying "all food must be seas…

> And I have as many bugs in the one as the other. The case for types is very strong in Javascript though. I also use Ruby for backend and TypeScript for frontend and see no problem with that. Some languages are well suited for dynamic. Sometimes not just due to the language but the community + culture around it. Ruby codebases are also very heavily test driven which helps compensate and the inherent flexibility/deve…

Seeing as you've adopted TS, have you had the chance to look into Sorbet? The Ruby type-checker?

Re: Phoenix 1.7 is View-less

#166

Post by dmpk2k »

travisgriggs wrote: post #61
enraged_camel wrote: post #25

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

For me personally, this is not the case. I work in multiple languages, some static, some not. And I have as many bugs in the one as the other. I add strings to numbers less in static ones, but I tend to make more design mistakes, because I have to steer through the constraints of the type system. I view "must have static types/compile time checking" types as a bit reductionist. It's like saying "all food must be seas…

I felt the same way about static types, until I had the misfortune to work on an absolute disaster of a codebase (happened to be in Javascript).

The worst case for a dynamically-typed codebase is so very much worse in high-level languages.

Admittedly, the immutable data structures in Erlang/Elixir help offset this.

Re: Phoenix 1.7 is View-less

#167

Post by josevalim »

blueblahvlah wrote: post #128

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

Re: Phoenix 1.7 is View-less

#168

Post by josevalim »

NhanH wrote: post #146
blueblahvlah wrote: post #128

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 (…

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

Re: Phoenix 1.7 is View-less

#169

Post by josevalim »

fud101 wrote: post #161
h0l0cube wrote: post #149

Earlier quoted context omitted.

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

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

Re: Phoenix 1.7 is View-less

#170

Post by dugmartin »

fud101 wrote: post #161
h0l0cube wrote: post #149

Earlier quoted context omitted.

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

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.

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

Post reply on HN