Live data from Hacker News

Phoenix 1.7 is View-less

germanvelasco.com

61–70 of 224 posts

Re: Phoenix 1.7 is View-less

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

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 seasoned with salt." Salt's a good seasoner. For some meals, it's a must have. For others, it's a nice to have. And for others, it actually detracts. Compile time checking fits in the larger context of what programming in a given language is all about. Syntax, libraries, ecosystem, tools, execution semantics, runtime components. All of these compose for an end result. And typing plays a different role for each composition.

I've been doing Elixir off-and-on for about 1.5 years now. The community is great. If I personally, had to lobby for "next big thing", it would be having a real IDE. I did Smalltalk for 20 years. I want an IDE where I work in modules/functions, not files and do/end syntax. I want a formatter that is not a PHD paper on generalized layout. I want refactoring tools. Inline macro expansion visibility. If I were independently wealthy, I would work on just such a thing in my spare time.

ElixirLS and VSCode are OK, but so so limited really.

What makes Elixir a standout candidate for a killer IDE experience is it's simplicity. Simple execution models make the language easier to model, navigate, and so IDEs don't need parse engines that are constantly needing updating (I'm looking at you Kotlin/Compose). Elixir as a language eats its own dogfood. It's sad to me that the Xerox Parc folks exploited this so beautifully with Smalltalk, but Elixir is stuck in the file editor mode still. :(

Re: Phoenix 1.7 is View-less

#62

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/

You can use gleam in an application that uses Phoenix for web plumbing pretty easily.

Re: Phoenix 1.7 is View-less

#63

Earlier quoted context omitted.

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

To me that's a non-issue. How are you going to access a website without internet anyways? If you're talking about "slow" internet, then use Alpine JS to run truly client-side things in those very rare cases.

Live View might still be applicable in some latency sensitive contexts: one of the first Live View demos was a server-side rendered animation hosted in US that played at a smooth 60 fps in Europe.

There are very few problems Live View isn't good for, and conversely, there are very few problems client-side single-page application are necessary for.

Re: Phoenix 1.7 is View-less

#64

Earlier quoted context omitted.

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

To me that's a non-issue. How are you going to access a website without internet anyways? If you're talking about "slow" internet, then use Alpine JS to run truly client-side things in those very rare cases.

These days the issue is mostly mobile clients, but even then offline support is unusual for sure.

Re: Phoenix 1.7 is View-less

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

> The community is full of very senior people who freely answer your noob questions.

The role of José Valim, the creator of Elixir, can't be understated. He's everywhere, he's got his hands in many of the top used libraries, and he's incredibly welcoming and responsive to all the inane GitHub issues I've opened over the years.

People wrongly compare Elixir to Ruby, but I wonder if he decided to recreate the welcoming and newbie friendly community and leadership of Ruby.

(Chris McCord, the creator of Phoenix, seems like a pretty swell guy too)

Also, a note on the upstream code: Elixir and its core libraries are some of the few projects you get a quick answer to your issues and they aren't closed because they've gone stale. 18 open issues, 5k closed on the core repo is an impressive ratio these days.

Re: Phoenix 1.7 is View-less

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

> I’m under the impression that using it comes with some sizable scaling problems

Interesting. I have the exact opposite impression (I'm not experienced in live view; only written 2 small utilities). Erlang (therefore elixir) is fundamentally distributed, so as you mentioned, it would defeat the purpose.

So why gives you that impression? LiveView is just a smart/reactive socket built on Phoenix that behaves just like any other elixir process right? Why would it specifically have scaling issues?

Re: Phoenix 1.7 is View-less

#67
post #59

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?

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 comments or otherwise, but then this drifts from reality due to not being updated.

I actually tried elixir and this is one of the main things that turned me off it.

Re: Phoenix 1.7 is View-less

#68

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…

But you don't get type checking as part of the build right?

Re: Phoenix 1.7 is View-less

#69
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 are you using for the component library? I was thinking of trying out Elixir and if there’s something that works well with it I’d rather start there than by trial and error.

Re: Phoenix 1.7 is View-less

#70

Earlier quoted context omitted.

@chrismccord If you’re reading this, would be super interesting to update this 7-year-old benchmark to use Live View (and the latest stack). Thanks for all you do btw.

Could even switch over to Bandit which was on a recent Thinking Elixir podcast > In recent performance tests, Bandit's HTTP/1.x engine is up to 5x faster than Cowboy depending on the number of concurrent requests. When comparing HTTP/2 performance, Bandit is up to 2.3x faster than Cowboy https://github.com/mtrudel/bandit

I don't think that 1.7 is going to really have bandit fully supported on launch: https://github.com/phoenixframework/phoenix/pull/5071

Once it is supported though, I will be on that for sure.

Post reply on HN