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

131–140 of 224 posts

Re: Phoenix 1.7 is View-less

#131

Post by sb8244 »

conradfr wrote: post #68
cultofmetatron wrote: post #54

Earlier quoted context omitted.

> ZERO react/JS nonsense. As someone who knows js really well, I love liveview's hooks system. the js interop is the bees knees and lets me save my js chops for where I really need it. Also, I can emit js events that get picked up server side and vice versa. ie: no having to write any ajax calls. My frontend can react to server events with very little boilerplate. Thats a WAY better proposition than merely zero js. P…

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.

Re: Phoenix 1.7 is View-less

#132

Post by sodapopcan »

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

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.

Re: Phoenix 1.7 is View-less

#133

Post by blueblahvlah »

preciz wrote: post #129
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 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 ind…

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

Re: Phoenix 1.7 is View-less

#134

Post by Existenceblinks »

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

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

Re: Phoenix 1.7 is View-less

#135

Post by preciz »

blueblahvlah wrote: post #133
preciz wrote: post #129

Earlier quoted context omitted.

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

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

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

Re: Phoenix 1.7 is View-less

#136

Post by blueblahvlah »

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

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.

Re: Phoenix 1.7 is View-less

#137

Post by dmix »

eclark wrote: post #111
el_nahual wrote: post #108

Earlier quoted context omitted.

We use LiveView extensively and one meaningful issue we have is users with intermittent connections on mobile. On a "normal" req/resp page, their intermittent connection would manifest as a blank then slowly loading page: things that the user understands as being the result (in a way) of "bad internet". With LiveView, the site simply becomes unresponsive. Nothing changes, and the user interprets this as the site bein…

Some of the 1.7 stuff has an alert banner that pops up when the connection is broken. I think that could really help. However I haven't put that in our app as I have seen other issues of flakey connection reconnect issues, and I would hate to make any of those more visible with a flashing notice. - https://github.com/phoenixframework/phoenix_live_view/issues... - https://github.com/phoenixframework/phoenix/issues/510…

> I would hate to make any of those more visible with a flashing notice.

idk I haven't used LiveView in production but an interface that offers a well designed fallback "refresh" button helps for unpredictable edge cases, more so than the negatives of added complexity, which yes implies failure but is also certainly better than failing to optimize for reality.

I ran into a similar hypothetical issues, that was really in practice an edge case, because we cached views for typical users. But I still provided a way to force reset of both server caches AND Localstorage caches because otherwise such an option was limited to advanced users/devs who either know backend or frontend.

This is win-win ultimately because the user feels taken care of even in niche failure edge cases and QA/devs doing testing aren't forced to use exceptional means to reset state.

Re: Phoenix 1.7 is View-less

#138

Post by throwawaymaths »

ch4s3 wrote: post #123
ketzo wrote: post #94

Earlier quoted context omitted.

In a large JavaScript codebase that's partway to being a TypeScript codebase, I find myself constantly having to insert `console.log` statements to find out what attributes some object actually has. Plus, our number one source of crashes and errors is unhandled null/undefined because someone didn't realize a parameter might be nullish. Static typing would basically eliminate both of those issues.

I hear this about big JS codebases but the 7 year old Elixir app I work on is many 10s of thousands of lines of code and we just don’t have that problem.

It's not nothing but it's rare. After about two years I finally had a type error. It wasn't horrible, though, just caused extra log lines.

Re: Phoenix 1.7 is View-less

#139

Post by throwawaymaths »

Jcampuzano2 wrote: post #67
ch4s3 wrote: post #59

Earlier quoted context omitted.

I really don’t get this, personally. I’ve worked in Java, Ruby, Typescript, Elixir, JS, and a bit of Elm and I literally never feel like I’m missing anything by not having static types in Elixir. This is doubly true with web based projects. What are people looking for that they might get from static types?

I used to think this, but nowadays I avoid any language that doesn't have static typing. The difference in tooling support/IDE completions I get on practically any language that has types vs those that don't is just too drastic for me. It's also so much less mental load to have to always remember the types in my head. Another issue I've seen in dynamic languages is when people do try to document the types via comment…

It's way less of an issue due to vscode/elixir-ls auto running dialyzer in the background

Re: Phoenix 1.7 is View-less

#140

Post by blueblahvlah »

sodapopcan wrote: post #132
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 (…

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

Post reply on HN