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

121–130 of 224 posts

Re: Phoenix 1.7 is View-less

#121

Post by dns_snek »

h0l0cube wrote: post #40
tiffanyh wrote: post #29

Earlier 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

Dialyzer is almost always right but I've been using Elixir for around 4 years and I occasionally still find it difficult to decipher its verbose and deceiving messages.

I previously worked with TypeScript which felt like a major productivity boost but I've ran into a few instances where Dialyzer came up with the most cryptic error message that took me at least an hour to figure out. It really sucks when that happens and I wish there were more high quality learning materials that would dive into Dialyzer.

Re: Phoenix 1.7 is View-less

#122

Post by andrewmutz »

lnxg33k1 wrote: post #24

Makes little difference to me, it has been few years now that I create API backends consumed by separated frontends, them being either CLI or JS etc. If anything for me this approach has done wonders for e2e tests using api mockservers But probably for simpler projects and new starters makes sense But I would really suggest anyone out there just to avoid backend-frameworks-based view/templating (guess json responses…

> But I would really suggest anyone out there just to avoid backend-frameworks-based view/templating (guess json responses are view layers) layers

Are there client-side rendered frameworks that can match the developer productivity of Phoenix or Rails for early stage, small team products? It seems they are still the best for small teams moving quickly in the early phases of a project.

Re: Phoenix 1.7 is View-less

#123

Post by ch4s3 »

ketzo wrote: post #94
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?

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.

Re: Phoenix 1.7 is View-less

#124

Post by viceroyalbean »

h0l0cube wrote: post #110
syspec wrote: post #95

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

Elixir-ls provides Language Server Protocol support as well as VS Code Debug Protocol support which gives extra powers to VS Code, NeoVim, Emacs, and the like. https://github.com/elixir-lsp/elixir-ls I do agree that automated refactoring would be an amazing productivity improvement.

Unless I did something wrong with my setup the elixir LS is kind of lackluster compared to a full IDE. It doesn't have any automatic refactoring (even variable renaming) nor does it provide automatic detection of syntax errors. It's pretty much just symbol lookup and some autocomplete functionality.

Re: Phoenix 1.7 is View-less

#125

Post by h0l0cube »

dns_snek wrote: post #121
h0l0cube wrote: post #40

Earlier quoted context omitted.

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

Dialyzer is almost always right but I've been using Elixir for around 4 years and I occasionally still find it difficult to decipher its verbose and deceiving messages. I previously worked with TypeScript which felt like a major productivity boost but I've ran into a few instances where Dialyzer came up with the most cryptic error message that took me at least an hour to figure out. It really sucks when that happens…

Yep, I've had some weird errors with Dialyzer, but in the mobile world I've had some similarly baffling errors from Kotlin and Swift, particularly around lambdas and generics. Let's not forget that the typing flexibility allowed in Elixir is really quite powerful compared to other languages. (e.g., function signatures can have guards, union types, and pattern matching)

I wish some LLM magic sauce could be applied to compiler and linter warnings in general that provide a context-appropriate plain language explanation, along with suggestions and automated fixes.

Re: Phoenix 1.7 is View-less

#126

Post by h0l0cube »

viceroyalbean wrote: post #124
h0l0cube wrote: post #110

Earlier quoted context omitted.

Elixir-ls provides Language Server Protocol support as well as VS Code Debug Protocol support which gives extra powers to VS Code, NeoVim, Emacs, and the like. https://github.com/elixir-lsp/elixir-ls I do agree that automated refactoring would be an amazing productivity improvement.

Unless I did something wrong with my setup the elixir LS is kind of lackluster compared to a full IDE. It doesn't have any automatic refactoring (even variable renaming) nor does it provide automatic detection of syntax errors. It's pretty much just symbol lookup and some autocomplete functionality.

I'll quote myself here:

> I do agree that automated refactoring would be an amazing productivity improvement.

Re: Phoenix 1.7 is View-less

#127

Post by calvinmorrison »

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 hear you, but working primarily in php, the amount of lines of correspondence to type checking is wearing

Re: Phoenix 1.7 is View-less

#128

Post by 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)

Re: Phoenix 1.7 is View-less

#129

Post by preciz »

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

Re: Phoenix 1.7 is View-less

#130

Post by sb8244 »

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 send it's entire form state to the server. That was my escape hatch because it worked inside of any component structure.

Post reply on HN