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

141–150 of 224 posts

Re: Phoenix 1.7 is View-less

#141

Post by frellus »

rahimnathwani wrote: post #97

What's the best way to get started with Phoenix 1.7, for someone with no Elixir experience? Should I learn some Elixir before diving into the Phoenix docs?

Personally I'd highly suggest investing in time in both, but start with basic Elixir and understanding the concurrency model and functional programming if you're coming from an imperative or OOP world.

If you like learning by watching videos, I cannot recommend this course highly enough, it's what accelerated me from zero to a lot of the key concepts:

https://codestool.coding-gnome.com/courses/elixir-for-progra...

The instructor speaks in a way that's easy to consume, for me. It assumes you already know how to program, and the way he talks about the various topics gives a lot of depth to the various concepts that's missing in a lot of material I've seen -- he explains the "why" of things, not just the "what" and "how".

The course will have you implement a hangman game from a basic client/server model, eventually to a Phoenix non-Liveview page, then to LiveView, so you get a great understanding of how to architect an application the right way and how to make good design decisions.

The whole thing costs just $35, which I think is perfectly reasonable and doesn't break the bank for anyone. The Pragmatic courses are good, but Phoenix is too out of date in them now and it'll cause a lot of pain if you're trying to follow along exactly. Phoenix has evolved quite a bit from 1.5 to 1.6 and now 1.7, and those changes can be a bit confusing to a first time person.

Other place to start would be just the basic docs on the Elixir and then Phoenix site. They're really good. Elixir School is also good (and free).

Re: Phoenix 1.7 is View-less

#142

Post by amalgamated_inc »

rahimnathwani wrote: post #97

What's the best way to get started with Phoenix 1.7, for someone with no Elixir experience? Should I learn some Elixir before diving into the Phoenix docs?

I would recommend some Elixir before you dive into Phoenix, yes. I learned from this website: https://alchemist.camp/

Lots of free tutorial videos.

Re: Phoenix 1.7 is View-less

#143

Post by amalgamated_inc »

sodapopcan wrote: post #20
ealdent wrote: post #16

So can we refer to LiveView’s counterpart as DeadView, now?

We actually already do! I have no links but click around https://elixirforum.com and you'll see referencing "dead views" often enough.

Can confirm, I say/hear "dead view" at least once a day ;)

Re: Phoenix 1.7 is View-less

#144

Post by amalgamated_inc »

davidatbu wrote: post #44

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

Re: Phoenix 1.7 is View-less

#145

Post by jamal-kumar »

tiffanyh wrote: post #6

Elixir/Phoenix has hit full-stride. I feel like the next big unlock in user adoption is continued improvements to BeamAsm. Hopefully something on the order of 100-200% raw performance speed up. Note: I’m talking about raw perf, not concurrency. A few other additions to Phoenix 1.7 include: - verified routes - tailwind built in - additional web server support (bandit) https://www.phoenixframework.org/blog/phoenix-1.7-…

I come from working with mostly golang for the past decade and have been very happy with it and its concurrency capabilities, but after playing with elixir for the past couple of weeks, I realize there's something to this, especially in terms of what it has to offer for distributed computing. Very cool to hear that they're working on making it more performant!

Re: Phoenix 1.7 is View-less

#146

Post by NhanH »

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

Re: Phoenix 1.7 is View-less

#147

Post by realusername »

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…

Elixir does have a very good autocomplete despite the dynamic typing, it's probably the best autocomplete I've ever seen for a non typed language.

The reason for that is simple, the language works with modules and data pipes, not objects which means there's way less magic to parse

Re: Phoenix 1.7 is View-less

#148

Post by rahimnathwani »

frellus wrote: post #141
rahimnathwani wrote: post #97

What's the best way to get started with Phoenix 1.7, for someone with no Elixir experience? Should I learn some Elixir before diving into the Phoenix docs?

Personally I'd highly suggest investing in time in both, but start with basic Elixir and understanding the concurrency model and functional programming if you're coming from an imperative or OOP world. If you like learning by watching videos, I cannot recommend this course highly enough, it's what accelerated me from zero to a lot of the key concepts: https://codestool.coding-gnome.com/courses/elixir-for-progra... Th…

Thanks. I’m on the pattern matching section of that course now, and and am loving the style so far. I like that the explanation isn’t solely dependent on the videos, too.

Re: Phoenix 1.7 is View-less

#149

Post by h0l0cube »

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.

Re: Phoenix 1.7 is View-less

#150

Post by pbowyer »

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…

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.
Post reply on HN