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

81–90 of 224 posts

Re: Phoenix 1.7 is View-less

#81

Post by Dowwie »

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

Typespec is a nightmare to work with. The error messages are arbitrary and at times misleading. I use it because it is better than nothing, but it has much room for improvement.

Re: Phoenix 1.7 is View-less

#82

Post by dmix »

TylerE wrote: post #80
dmix wrote: post #76

Earlier quoted context omitted.

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.

Does that include deploys?

Re: Phoenix 1.7 is View-less

#83

Post by wstuartcl »

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…

there are not a ton -- the pain points mostly boil down to:

Don't use it for extremely latency sensitive UI's (there is around trip and most of the time for most uis this is not an issue even using a server across the world).

Don't use it for animation heavy UIs (you can do animations with it but think things like game UI).

It does not work offline (in most cases it s the same point with standard web and offline).

All of that said, the answer to your second "question" is: There is a process (this is an erlang process and VERY light -- much lighter than a thread its not unusual to have millions of them running at a time in beam) per active page. So one per use per tab or session.

Also yeah, there is no lock in -- you can have 99% of your pages use static rendering (dead pages) and just use liveview for the ones that would benefit. The choice does not come with sharp edges.

Re: Phoenix 1.7 is View-less

#84

Post by ch4s3 »

panzi wrote: post #72
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?

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

I’ve worked on some pretty large codebases and while there’s usually no IDE button for it, there are good and well known patterns for refactoring dynamic code.

As for bugs, the research on this has always been mixed at best, I guess YMMV.

I’d personally argue that the structural typing in Elixir is more useful and practical than the types in most popular static languages like Java or TS.

Mostly I think it’s a wash where you get a little but give up some useful things too.

Re: Phoenix 1.7 is View-less

#85

Post by micmus »

tiffanyh wrote: post #29
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.

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?

The type checker from WhatsApp is open sourced and actively used. See https://github.com/WhatsApp/eqwalizer

Re: Phoenix 1.7 is View-less

#86

Post by emerongi »

sph wrote: post #71
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.

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…

A type system saves a lot of time when reading code that has been written by other people and has evolved over time. In Elixir, I often end up adding debugging statements to code and running it, just to check the data structures.

A type system also gives additional assurances when changing code that is used from many places. It's so nice to make a change and have additional confidence in it because the type system is happy with it.

I can't think of many bugs that I've seen that would have been prevented by a type system. I'd still like to have a type system though, it's sort of extra documentation within the code.

Re: Phoenix 1.7 is View-less

#87

Post by travisgriggs »

granshaw wrote: post #78
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…

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

That would make sense. More information, better IDE.

But it has not been my experience. Nor some of my peers. Despite a meh text editor, the Smalltalk IDEs (Smalltalk/V, VisualWorks, and VisualAge) were amazing. The original "refactoring" work done by John Brant and Don Roberts was pioneered at UIUC in these environments. Their adaptation to the different IDEs just improved them.

I remember sitting next to John and Don at OOPLSA and speculating that refactoring inside of Java (Eclipse was The New Editor at the time) should be superior in Eclipse vs Smalltalk because Java had more type information to work with. John and Don, both Smalltalk enthusiasts in those days, admitted they had anticipated that as well. And they did a bunch of work trying to port refactoring stuff to Eclipse. They were surprised to discover it wasn't so. But it's not typing vs not. It's simplicity vs not. When I asked if that meant that rising start Ruby would benefit from their refactoring work, they said that too was hard. Don explained that in a nut shell, it was the AST. Much of what tools/IDEs do is work with a model of the language. The Smalltalk AST had 15 polymorphic objects to represent its language model. Ruby was 90+ and climbing at the time. Java was insane. Their take was that while typing might add some information, the combinatorial explosion of modeling the language just made tooling for the language more difficult. It was an interesting insight.

Elixir/Erlang has a language model that is even simpler than Smalltalk in some ways. The trickiest part is the macros.

Re: Phoenix 1.7 is View-less

#88

Post by wstuartcl »

cultofmetatron wrote: post #51
Crazyontap wrote: post #3

Speaking as an amateur programmer, is this like Laravel's livewire or intertiajs with inline blade component? (but in Elixir). Or is this something else?

live view is the original and best. imitators use long polling to periodically check for updates. liveview spins up a dedicated vm process for each active user and can push updates over websocket to update things. This process can do things like listen for serverside events as well.

It may be redundant but I think its always important to note that processes as listed above are not like os processes here -- but an extremely lightweight internal VM thread like thing in the BEAM VM. In is not uncommon to have many millions running in the beam VM. Very much lighter than threads or OS processes.

Re: Phoenix 1.7 is View-less

#89

Post by wstuartcl »

cultofmetatron wrote: post #54
sergiotapia wrote: post #8

I'm building a startup in my free hours using Phoenix Liveview. I can ship features in hours vs days thanks to the simplicity liveview gives me. ZERO react/JS nonsense. I back to writing server side rendered templates with for-free reactivity. Give it a try it's very productive

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

Yeah its JS where you want JS and no where else.

Re: Phoenix 1.7 is View-less

#90

Post by wstuartcl »

password4321 wrote: post #11
sergiotapia wrote: post #8

I'm building a startup in my free hours using Phoenix Liveview. I can ship features in hours vs days thanks to the simplicity liveview gives me. ZERO react/JS nonsense. I back to writing server side rendered templates with for-free reactivity. Give it a try it's very productive

The downside as I understand it is the extra work to manage UX for connections with high latency and/or going offline, correct?

Yes and no.

It handles crappy connections ok -- it will auto reconnect as needed.

As far as full offline -- it has interfaces to easily alert the user via UI that they are disconnected, however, just like 99.999% of non liveview apps when you are offline things start breaking (load just about any static page site and submit a form or navigate when offline).

Post reply on HN