Phoenix 1.7 is View-less

https://www.germanvelasco.com/blog/phoenix-1-7-is-view-less

by todsacerdoti • 4 years ago

345 220 4 years ago

drannex• 4 years ago

This definitely reduces some of the cognitive overhead of designing out a Pheonix service, thats for sure. A really welcome change in my eyes.

Crazyontap• 4 years ago

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?

thedangler• 4 years ago

livewire was inspired by liveview. I think livewire 3 will be more like the newer version of liveview

bnt• 4 years ago

Well, unless it moves completely to Websockets, it will still remain a slow mess.

jnsaff2• 4 years ago

I think livewire was inspired by phoenix liveview. I remember there was even a podcast interview about it.

freedomben4• 4 years ago

Yes, there are a lot of similarities. As mentioned in siblings, Livewire was inspired by LiveView so they are directly related.

cultofmetatron2• 4 years ago

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.

wstuartcl8• 4 years ago

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.

metaltyphoon• 4 years ago

Pig backing here… is this like Blazor server-side?

ch4s39• 4 years ago

Yes, Blazor is inspired by LiveView.

tiffanyh7• 4 years ago

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

enraged_camel• 4 years ago

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.

tiffanyh7• 4 years ago

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?

sodapopcan4• 4 years ago

Based on the number of attempts to add static typing to Erlang, I don't see this ever happening.

I know the author of Gleam is going full-time working on it, but I really know much about it or how it gets around the problems with statically typing message-passing. I'm perfectly happy working in dynamic languages and find Elixir's type hinting to be more than adequate.

ch4s39• 4 years ago

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?

travisgriggs2• 4 years ago

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. :(

sph3• 4 years ago

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.

sugarpile• 4 years ago

I’m currently doing two startups: one with rapid consulting-esque development and one more long term B2B one. I would 100% be using Phoenix for the the majority of the projects in the former if it had static typing. Have been a fan since release but, for me, it’s a hard requirement for anything that isn’t a personal project

sethammons• 4 years ago

I left elixir and went back to Go because statistic typing.

The elixir project I was in had several dozen developers on it and specs were not enough. I always had to backtrack through several calls and/or run the code and dump the data and then capture the example data as a comment so future devs could know what was coming into the function. Not a great solution.

syspec• 4 years ago

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!

Kototama• 4 years ago

You are missing a lot of the best tech out there in the programming world if you are waiting for an IntelliJ-like IDE for each programming language.

h0l0cube11• 4 years ago

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.

subbu• 4 years ago

I really wish intelli-j provides a first-class editor. I could never get VSCode + ElixirLS to work smoothly. It's just broken. I have switched to NeoVim + plugins. It feels better mostly because of Vim's eco-system. But I am missing a lot of productivity due to lack of a good IDE.

jamal-kumar• 4 years ago

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!

gnutrino• 4 years ago

This makes sense to me. Views always seemed a like unnecessary boilerplate to me. Better to keep all the code together in one module, and just import common functions. On the other hand, I don't typically like defining the template in a sigil, unless it's a really small one, so I probably won't do that much.

freedomben4• 4 years ago

I agree in the case of HTML rendering, but I write a lot of JSON APIs and putting the JSON definition in the View has been very pleasant. It didn't say in OP, but how does this change an API? Maybe a `GreetJSON` instead of `GreetHTML`?

a_bored_husky3• 4 years ago

Yes, exactly like that.

eclark9• 4 years ago

Correct. You write a moduleJSON. So this is about what we have for one of our controller/views:

  defmodule MyWeb.SystemStateJSON do
    def index(%{summary: summary}) do
      %{data: summary}
    end
  end

sergiotapia4• 4 years ago

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

password43212• 4 years ago

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

freedomben4• 4 years ago

Yes, the downside is basically offline. When offline the LiveView app doesn't work because it can't update it's DOM. A decent solution I've enjoyed is using Alpine.js. It fits very neatly into the LiveView philosophy and can do nearly all UI updating easily. It still minimizes the amount of JS you have to write but you get good client-side update behavior.

High latency isn't an issue if you do it correctly by using the loading classes and what not so that the user knows they are waiting for some data to load. It's pretty much identical to a typical React SPA that has to show loading indicators while waiting for a JSON call to complete.

a_bored_husky3• 4 years ago

You aren't suppossed to use LiveView for every interaction, only the ones that require the server to be involved somehow just like a regular SPA. For pure client-side interactions LiveView has some utilities like LiveView.JS or you can use a lib like AlpineJS.

sergiotapia4• 4 years ago

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.

wstuartcl8• 4 years ago

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

benatkin2• 4 years ago

You six months ago: "I hate Java. Can I use Kotlin without touching it whatsoever?" https://news.ycombinator.com/item?id=32037125

You realize that js and java are the native languages for the web and Android, right?

anamexis• 4 years ago

What is your point?

cultofmetatron2• 4 years ago

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.

PS: the frontend buildchain is esbuild so you get out of the box support for typescript.

conradfr3• 4 years ago

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

wstuartcl8• 4 years ago

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

oDot• 4 years ago

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

sodapopcan4• 4 years ago

As it stands you have to write a separate API, though there is work being done on native [0].

Otherwise, part of the initial value-prop of LiveView is that if you don't need multiple frontends and you don't need offline support--which a whole lot of apps don't--then LiveView drastically simplifies your stack while still delivering "SPA-like" speed.

[0] https://native.live/

a_bored_husky3• 4 years ago

You would need to write the REST/GraphQL API. Maybe with help from Ash Framework (https://ash-hq.org) to make it easier to reuse logic.

sergiotapia4• 4 years ago

I use Absinthe to expose a graphql API endpoint.

The Absinthe resolvers just call the contexts/functions my liveviews call anyways.

Alacart• 4 years ago

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.

di4na• 4 years ago

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.

freedomben4• 4 years ago

Hex Docs for Phoenix.View mention the change: https://hexdocs.pm/phoenix_view/Phoenix.View.html#module-mig...

Phoenix.View is replaced by Phoenix.Component:

With Phoenix.LiveView, Phoenix.View has been replaced by Phoenix.Component. Phoenix.Component is capable of embedding templates on disk as functions components, using the embed_templates function.

More on hexdocs.

andy_ppp• 4 years ago

I was going to come here and link directly to this - the migration from previous versions is always covered in detail and seems to always work which is great. A lot of frameworks seem to struggle with this quality of documentation when upgrading versions.

ealdent• 4 years ago

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

sodapopcan4• 4 years ago

We actually already do!

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

amalgamated_inc4• 4 years ago

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

eclark9• 4 years ago

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 not hard to get something that's exciting.

- Elixir is a very nice language to write distributed systems in. Functional in all the right places plus it has OTP.

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

- On-boarding people has gone well. The syntax is friendly enough that experienced engineers grasp the basics, leaving functional programming and OTP left to discover.

eddsh1994• 4 years ago

What does your startup do? I'm not 100% sure based on the blurb, but keen to see product ideas where that tech stack shines :)

eclark9• 4 years ago

We haven't launched yet (Q1 Next year is the target), so the landing page isn't great yet.

We're a platform as a service that you can install on any cloud via Kubernetes, or on your own self hosted Kubernetes.

So distributed systems, automated remediations, machine learning ops, etc are the areas we're using elixir.

tiffanyh7• 4 years ago

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.

eclark9• 4 years ago

LiveView has been pretty great. Mostly it's just a couple of `handle_event` methods away and we have a fully reactive UI.

I haven't seen any scaling issues for LiveView. Under the hood there's a websocket that push and pull events from a running GenServer for each session. Since each process is independent it's horizontally scalable as long as your able to route websockets to the same process in a cluster.

While not the same, I do know that single machine has been able to scale to a couple of million connections ( https://www.phoenixframework.org/blog/the-road-to-2-million-... ) with phoenix channels. Which are harder to scale than independent live views. Also our use case is for smaller scale than that (Not too many companies have a million people looking at their ml deploy pipelines) so I haven't been too worried.

hn92726819• 4 years ago

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?

josevalim6• 4 years ago

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. :)

Mizza• 4 years ago

I'm also doing a solo-startup right now that relies heavily on LiveView and Channels/Websockets. I wouldn't have been able to build it by myself without Elixir/Pheonix. It's absolutely fantastic, can't recommend it highly enough.

sickcodebruh• 4 years ago

How did you settle on Elixir/Phoenix? Did you consider any other languages + frameworks?

eclark9• 4 years ago

100% this. I started with it solo and I was able to achieve what would have been very hard for a three person team with the standard js app + api app + backend app.

sph3• 4 years ago

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.

mlambie• 4 years ago

To highlight this point, Jose’s in this thread and across HR. He’s an inspirational leader.

brigandish2• 4 years ago

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.

eclark9• 4 years ago

I would recommend Petal: https://petal.build/ It's what I used for quite a while and I think it's the most comprehensive currently.

We're building two different UI's that share a common design language so we ended up creating a common UI application in the umbrella project.

ctvo3• 4 years ago

Elixir is a very nice language to write distributed systems in. Functional in all the right places plus it has OTP.

This is the biggest blocker for introducing Elixir to any company I work at. I don't want to become / hire experts in the OTP and the Erlang VM.

I'm ignorant about it in general, but my feeling is it's not only a new language, it's built on abstractions that I'm not sure I'm comfortable owning or operating. Is that wrong and how did you handle the tradeoffs for your company?

bongobingo1• 4 years ago

You can kinda ignore OTP outside of the initial "run these (erlang) processes when the vm boots", which is a few lines - often scaffolded out automatically.

But then when you suddenly need some async task x service x parallelism its there.

I guess if you're building a company it does behoove you to at least read a bit about it but you don't need every team member to be an OTP expert. If you can understand how an OS runs processes at the most basic level and how javascripts async/await works you're already most of the way in a practical day-to-day sense.

throwawaymaths4• 4 years ago

The abstractions you need to critically know are map and reduce. It's not functional like Haskell, the limit at which you need to "think about it being functional" is that a value inside a variable can't change from underneath you when you pass it to a function. It pretty quickly changes from "I have think about values not chamging" to "I don't have to worry about values changing"

eclark9• 4 years ago

Ignore OTP for the most part. Just write good code that works at one level at a time. Then when you hit something that needs OTP I send them towards Designing Elixir Systems with OTP

https://pragprog.com/titles/jgotp/designing-elixir-systems-w...

This is all about the onboarding experience of engineers coming onto a team. So you have to be careful with the projects that engineers newer to elxir get. But that's part of the cost of a more niche language.

Fire-Dragon-DoL5• 4 years ago

My answer to this is the following: do your software have by any chance, SQL writes and HTTP request to any third party APIs within the same endpoint? Or maybe it uses some background job processing that's not SQL based and you have at least one endpoint where a job is enqueued AND something is written with SQL?

If the answer is yes, you already have a distributed systems with all the downsides and none of the mitigations.

If that's the case, you can also use Elixir without still knowing anything and have the same level of penalties.

It's really hard nowdays to avoid distributed systems, it just happen that people don't realize they have one.

The classic Rails + Postgres + Sidekiq is a distributed system

dooven• 4 years ago

This has been awesome. I'm currently using the new Phoenix 1.7 generator to build https://locationsquared.com/ and I used the view-less layout to have a small helper function to build the meta tags for each pages.

lnxg33k13• 4 years ago

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 are view layers) layers

thex10• 4 years ago

But I would really suggest anyone out there just to avoid backend-frameworks-based view/templating

I personally struggle to let go of backend templating. It's so easy to translate your data into the right pieces of markup in the template, and just serve the fully-baked HTML to the user instantly. How should I be looking at this differently?

lnxg33k13• 4 years ago

I think few reasons that made me go with this new (for me, at the time) approach were:

- Backend/API that can be consumed by anything, are frontend-agnostic

- Frontend that depends on JSON/source-agnostic data so that can have functionality tested faster (no "proper"/"dynamic" backend involved, just give it some ApiBlueprint/swagger mock server

- The frontend rendering isn't a concern of the backend removing some load

gedy• 4 years ago

As company gets larger, it's so nice to have "important business logic" via API only, that way mobile apps, web apps, partners, etc can use same logic/data. Server side templating is a real drag on enabling this.

andrewmutz• 4 years ago

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.

lnxg33k13• 4 years ago

So, I am not sure what kind of developer productivity are we talking about, I think it's about what people are comfortable with and know of. I am a solo dev working on a side project with rust+phoenix backends (one doing IO-intensive/Multithreading stuff and the other presenting the info/business logic through API) and svelte frontend and svelte for me is very simple. On the other hand if there's an emphasis on developer productivity, and your team has experience on Phoenix/RoR, then you can't fight experience

thriftwy• 4 years ago

So did the MVC model just got stripped down to just C, a.k.a. Servlet but with more amenities?

h0l0cube11• 4 years ago

I feel like the title is a bit misleading. All 3 are still uncoupled, it's more that the V and C is now cohered in the directory structure, which seems a bit more ergonomic.

rjh29• 4 years ago

I love how web development has gone full circle. In 2006 I wrote a chatroom site that was server-side with Ruby on Rails-based javascript sprinkled in for realtime page updates. It was long polling of a single HTTP request (websockets didn't exist then) but it worked extremely well. Never liked SPAs and the npm bloat. Happy that stuff like Svelte and Phoenix is taking it back to the server-side with JS sprinkles place which seems optimal to me.

davidatbu4• 4 years ago

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/

ch4s39• 4 years ago

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

davidatbu4• 4 years ago

Good to know!

wstuartcl8• 4 years ago

I think if you actually try elixir you will find its lack of typing to be of little concern.

davidatbu4• 4 years ago

Gotcha. Appreciate the encouragement!

amalgamated_inc4• 4 years ago

Remember, he who types statically types twice the amount and thus half as fast. There's honestly no need for static typing in Elixir.

davidatbu4• 4 years ago

he who types statically types twice the amount and thus half as fast.

If you mean by this, "static typing is not worth the effort", the zeitgeist is definitely not with you on this one.

There's honestly no need for static typing in Elixir.

I'd love for that to to be the case! Is the only way for me to find out for me to give it a try, or are there somethings you can say to help me believe?

tobyhinloopen• 4 years ago

So many great changes! I can’t wait!

I’ve been using Phoenix / Elixir since 2016 and i’ve been really happy with it

rahimnathwani4• 4 years ago

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?

pjm331• 4 years ago

With the caveat that I’ve only dabbled with elixir and Phoenix for side projects

I really liked the approach taken in this book - https://pragprog.com/titles/lhelph/functional-web-developmen...

In which you first build out the functional core in just elixir and then hook up Phoenix as the web interface

frellus3• 4 years ago

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

rahimnathwani4• 4 years ago

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.

amalgamated_inc4• 4 years ago

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

Lots of free tutorial videos.

mxgrn• 4 years ago

I would recommend reading these 2 books in parallel: Elixir in Action by Sasa Juric (one of my favorite programming books in general), and Programming Phoenix from PragProg. And before that, to wet your appetite and get a feel for the Erlang VM, watch a small video by Sasa Juric on youtube: https://www.youtube.com/watch?v=JvBT4XBdoUE

rahimnathwani4• 4 years ago

Thanks for these recommendations. I'm now part way through the book, and have been amazed at the clarity with which Sasa writes.

Then today I watched half of the video, and was blown away by how clearly he communicates, even when (or especially when?) he's speaking twice as fast as most people delivering presentations.

rsrsrs86• 4 years ago

José Valim is amazing

blueblahvlah6• 4 years ago

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)

preciz2• 4 years ago

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.

blueblahvlah6• 4 years ago

https://github.com/phoenixframework/phoenix/issues/4975

sb82444• 4 years ago

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.

pbowyer2• 4 years ago

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.

sodapopcan4• 4 years ago

Heex and components are essentially one-in-the-same. Heex enabled components upon its release and now the framework is (rightfully) pushing components.

Forms I agree with, though I don't feel that pain too badly. Having to be more explicit than just passing in raw parameters to an update function actually has its benefits (though I'm sure better forms are coming along).

Agreed that the framework is moving faster than the available literature on it, though people are doing their best and are doing a pretty good job of keeping up.

What is it about the boilerplate that annoys you? It's quite a bit less than Rails, though that's my only point of comparison unless you're going to unfairly compare it to a microframework. There aren't any generated files that I'm not thankful I can easily edit if I need to.

blueblahvlah6• 4 years ago

W.r.to boilerplate - I have no reference point/comparision to other frameworks.

When the project grows with more contexts, components and forms, one will end up with a bunch files which differ only in Module.func_names.

Phoenix < 1.7, View files which are required for controllers are boilerplate which contain 3-4 lines. In the end there will be a folder with view files which don't will have similar content unless any view specific functions are added.

Existenceblinks4• 4 years ago

- Engineering culture

As oppose to php, ruby, javascript culture which is; make/build/ship stuff to the world. IMO, this is the growth stopper. I couldn't care less about sophisticated clean architecture, module boundary, nice pooling http clients, principle goodness. The second growth stopper is jobs. Good luck finding future elixir developers if you do not help build the elixir army. Companies be like, lets choose birth control and adopts senior elixir devs instead.

treadmill2• 4 years ago

That... that is why you fail.

blueblahvlah6• 4 years ago

In my original post:

- there was leex, then heex, now components taking centre stage.

- most of the books, tutorials, videos, articles are stale due to frequent changes / evolution

Last two points should have been one. Got split while composing the post. My mistake.

- there was leex, then heex, now components taking centre stage. most of the books, tutorials, videos, articles are stale due to frequent changes / evolution

I am OK with evolution. From project maintainance and developer - its a challenge to keep up with things coming their way.

wstuartcl8• 4 years ago

regarding frequent changes, in my experience keeping 5 or 6 Phoenix/Liveview apps up to date the pain I have seen with changes is far less than I have experienced with Rails, Django and even front end updates required to keep react and vue inline. All of that when Liveview is not even a 1.0 yet...

I do get that books and other rotting materials obviously fall behind quickly but have you seen hard uplifts to codebases to keep them up to date?

NhanH2• 4 years ago

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.

josevalim6• 4 years ago

The integration is still there and it is mentioned in our assets guide: https://hexdocs.pm/phoenix/asset_management.html#third-party...

Regarding import maps, I am still slightly skeptical. First they don’t solve all needs of npm (for example, what if you need to precompile your FE code?). Second, I have feeling that every import map management tool will eventually become a package manager through slowly creep in of requirements. At the same time, there is nothing stopping anyone using it on their Phoenix apps if they so desire.

h0l0cube11• 4 years ago

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.

blueblahvlah6• 4 years ago

https://news.ycombinator.com/reply?id=34193789&goto=item%3Fi...

fud1012• 4 years ago

it takes like 6 lines of code to have a working flask endpoint to deploy a quick and dirty API. About a billion files for phoenix. I hate that too.

josevalim6• 4 years ago

- still evolving and releases are breaking (no backward compatibility)

To clarify, this is only true for LiveView which has not reached v1.0 yet. Even then, we have been careful with deprecations while exploring a new programming model with several new ideas.

In fact, Phoenix v1.7 is precisely the consolidation of those ideas. I’d say Phoenix v1.7 would be tagged as v2.0 in most web frameworks, but we kept it as v1.x exactly because it is still backwards compatible (and it has been so for 7.5 years!).

The last steps before LiveView v1.0 are likely forms (which you mentioned) and perhaps a better mechanism to stream with appending/prepending/replacing data.

Once it is out, we hope the remaining cons will be quickly addressed, except the boilerplate bits. The boilerplate is always a trade-off: if we hide too much, then the pieces become more coupled and it is harder to understand how they fit together. So I’d say Phoenix strikes the right balance here and if you have a highly formulaic application, projects like Ash may be to your taste. :)

conradfr3• 4 years ago

All web frameworks fail with forms one way or the other :)

I think one point would be the docs, to outline the basic cases, best practices. Maybe something tying the form helpers and changeset together.

I have a side project [0] with a form which have inputs dependant of others and a dynamic section (assoc).

I struggled a bit with the data, checking what I would get inside a changeset struct, until I "discovered" get_field and put_change.

For the assoc I was also a bit lost until I read an article using a delete virtual field. In the end I made it work but I still not sure I used all the right changeset functions.

To LiveView credits this app has been used all over the world and got very good feedback, nobody mentioned any lag issue etc (well, someone with a crappy connexion in Istanbul once got an incomplete uploaded file without getting an error).

[0] https://github.com/conradfr/FunkyABX

hartator• 4 years ago

but we kept it as v1.x exactly because it is still backwards compatible

I would say a big philosophical change like dropping Views is backward incompatible. You can’t use old tutorials now.

treadmill2• 4 years ago

Elixir/Phoenix Community is small and non toxic on forums

Golang taught me to appreciate this when choosing a language. The tone of the community made me look elsewhere.

The Elixir community is indeed very friendly and helpful!

revskill• 4 years ago

The main issue, is there's no demo !

Alifatisk2• 4 years ago

What is the Rails equivalent to Livewire? Actioncable? Hotwire? InertiaJs?

danieljacksonno• 4 years ago

Hotwire

Alifatisk2• 4 years ago

Does StimulusReflex count?

d_sc• 4 years ago

LiveView is evolving into a great piece of tech, but as others have noted elsewhere in the comments one of the challenging parts with LiveView right now (and to an extent Phoenix) is the outdated books & tutorials.

Bruce Tate and Sophie DeBenedetto have been authoring the book “Programming Phoenix LiveView” (https://pragprog.com/titles/liveview/programming-phoenix-liv...) which has the potential to be a great source for people that want to really dive into LiveView. The challenge though is they have not updated it to support the changes introduced in 0.18.0 which makes it really hard to start using the book when a new Phoenix application “mix phx.new dev_app” looks different than what’s in their book and some of their code breaks with the default installed versions of included plugs.

While I wish the book would receive an update sooner that brings it back to a compatible state (meaning there are no issues following along with the book), the good news is they have committed to having the book be updated when LiveView hits 1.0.

blueblahvlah6• 4 years ago

Any link/doc of roadmap for LiveView from 0.18.3 to 1.0 ?

[edit] I like the Project Status section of bandit - https://github.com/mtrudel/bandit#project-status

_a_a_a_• 4 years ago

Just what is it? I can't find a simple one sentence description

kevinplusone• 4 years ago

Was excited to hear views are being dropped. Been creating Web applications for over 20 years and have seen very little benefit of using views. Always saw them as an extra layer to think about, especially when trying to find where a function/method is defined when maintaining code. I think the MVC/MVVC ideas as applied to Web development were a step forward in getting people to organize code in general, but a step backward in keeping coherent, colocated, and maintainable code as projects grow. I've found that reusable encapsulated components for structure and well documented utility classes for CSS styles have always been the most helpful tools for creating maintainable Web applications, which seems to be the direction Phoenix and LiveView are going.

Phoenix 1.7 is View-less

Related Stories