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

71–80 of 224 posts

Re: Phoenix 1.7 is View-less

#71

Post by sph »

enraged_camel wrote: post #25
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-…

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.

Every time people talk about static types and the lack of them in Elixir I chime in to repeat that it is a misconception to think of typing as a black and white issue.

Typing systems exist on a spectrum: I constantly get type issues on Javascript and Python, refactoring is a nightmare without a ton of tests, while it was never a big issue in Elixir. Yes, its typing system is inadequate, and dialyzer isn't great, but in practice it is not that much of a problem. Pattern matching saves the day, and type errors found in rarely used code paths, what's the worst they can do? Crash the process? That's the least of our problems on the BEAM.

I've maintained a big data ingestion system that kept getting fed with bad, unforeseen data and it's never gone offline in the 3 years I've overseen its operation. If a bug causes your program to segfault or throw a NullPointerException, you will definitely want to have a strong typing system.

Re: Phoenix 1.7 is View-less

#72

Post by panzi »

ch4s3 wrote: post #59
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.

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?

For me:

- Ease of refactoring once the project got to a certain size.

- Preventing a lot of my stupid bugs (typos, passing the wrong type etc.).

- Quicker and easier understanding of argument and return types. The types are a form of documentation!

- Auto-completion and inline docs for library functions.

- Fewer tests needed, since everything the type system does has to otherwise be tested by a manually written test.

Just things anyone would tell you that appreciates static typing.

Re: Phoenix 1.7 is View-less

#73

Post by josevalim »

tiffanyh wrote: post #32
eclark wrote: post #19

We're building a startup ( https://www.batteriesincl.com/ ) with Elixir and Phoenix 1.7rc (git master really). It's been amazing; I could not be happier. - We went hard on components and it's made building UI's easy. In fact I wrote a test library to make component testing easier. - Live view is so easy with a good component library. I'm not a designer, but with snappy interactions and easy to use components, it's no…

What’s been your experience with Live View? I ask because I’m under the impression that using it comes with some sizable scaling problems, which somewhat defeats the point of using Erlang in the first place. I could be wrong though. Would like to learn more.

Each LiveView requires a persistent WebSocket connection to the server. This means it does have a different scaling profile than the usual request/response lifecycle, but the Erlang VM is greatly capable of holding millions of connections at the same time and therefore is a perfect fit for the LiveView model.

In fact, LiveView is built on top of the same Phoenix Channels we used to achieve 1 million connections on a single server. So I would say that LiveView fully leverages the Erlang VM strengths. :)

Re: Phoenix 1.7 is View-less

#74

Post by ch4s3 »

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…

Completions in Elixir in VSCode are as good as anything if seen in intellij for Java, through that may be a low bar.

As for the burden of the mental model, I can’t really speak to that. In Elixir I usually try to think in data shapes or structures which can be matched on by function heads. I only think of types at the edges of the system.

Re: Phoenix 1.7 is View-less

#75

Post by tiffanyh »

josevalim wrote: post #73
tiffanyh wrote: post #32

Earlier quoted context omitted.

What’s been your experience with Live View? I ask because I’m under the impression that using it comes with some sizable scaling problems, which somewhat defeats the point of using Erlang in the first place. I could be wrong though. Would like to learn more.

Each LiveView requires a persistent WebSocket connection to the server. This means it does have a different scaling profile than the usual request/response lifecycle, but the Erlang VM is greatly capable of holding millions of connections at the same time and therefore is a perfect fit for the LiveView model. In fact, LiveView is built on top of the same Phoenix Channels we used to achieve 1 million connections on a…

Thank you Jose for all you do, create and how you help developers around the world.

Re: Phoenix 1.7 is View-less

#76

Post by dmix »

josevalim wrote: post #73
tiffanyh wrote: post #32

Earlier quoted context omitted.

What’s been your experience with Live View? I ask because I’m under the impression that using it comes with some sizable scaling problems, which somewhat defeats the point of using Erlang in the first place. I could be wrong though. Would like to learn more.

Each LiveView requires a persistent WebSocket connection to the server. This means it does have a different scaling profile than the usual request/response lifecycle, but the Erlang VM is greatly capable of holding millions of connections at the same time and therefore is a perfect fit for the LiveView model. In fact, LiveView is built on top of the same Phoenix Channels we used to achieve 1 million connections on a…

What situations would face possible issues with the persistent-socket-per-view approach? A sprawling app with hundreds of distinct views that over-use LiveView? Would there also be multiple persistent sockets for each particular page?

I can't imagine the type of site that would need that sort of structure. Typically you'd have your highly-interactive primary subset of your app, about <10-25% of the routes/views which gets 75-90% of your traffic. While the other 75%+ of routes are just simple static-y/REST CRUD/server-rendered pages.

Re: Phoenix 1.7 is View-less

#77

Post by di4na »

Alacart wrote: post #58
oDot wrote: post #9

People using Phoenix Liveview -- how do you serve native apps relying on the same backend?

like others have said, you'd probably write a JSON API separately. One thing I'll mention though, is that the conventional design of Phoenix to use context modules often makes that very easy, in that your liveviews and API can just call the same business logic functions to crud resources.

This. As long as you keep the API relatively simple, something like basic CRUD "restful", it is really low cost to transform your domain model modules (regularly called "Context" in the community) into whatever JSON you need.

It is just two different presentation of the same data, so you do the work on the data model and the way to access it in elixir, then you just thinly wrap it in the API for it.

Re: Phoenix 1.7 is View-less

#78

Post by granshaw »

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…

Isn’t that abit chicken and egg tho? Static typing is what really makes a language amenable to powerful IDE functionality…

Re: Phoenix 1.7 is View-less

#79

Post by dmix »

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…

> 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/developer experience of Ruby can't be matched. Elixir being the only close match.

Re: Phoenix 1.7 is View-less

#80

Post by TylerE »

dmix wrote: post #76
josevalim wrote: post #73

Earlier quoted context omitted.

Each LiveView requires a persistent WebSocket connection to the server. This means it does have a different scaling profile than the usual request/response lifecycle, but the Erlang VM is greatly capable of holding millions of connections at the same time and therefore is a perfect fit for the LiveView model. In fact, LiveView is built on top of the same Phoenix Channels we used to achieve 1 million connections on a…

What situations would face possible issues with the persistent-socket-per-view approach? A sprawling app with hundreds of distinct views that over-use LiveView? Would there also be multiple persistent sockets for each particular page? I can't imagine the type of site that would need that sort of structure. Typically you'd have your highly-interactive primary subset of your app, about <10-25% of the routes/views which…

IIRC (don’t claim to be an expert) the main issue is gracefully handling the case where the server end goes away unexpectedly - network issues, reboots, that kind of thing.
Post reply on HN