Phoenix 1.6, RC0 released

https://www.phoenixframework.org/blog/phoenix-1.6-released

106 60 5 years ago

Phoenix creator here – I'm happy to answer any questions about elixir, phoenix, or this release!

CrownSoft5• 5 years ago

When learning elixir and phoenix, it is hard to find updated tutorials. Whenever I try an youtube tutorial, there is always an error. Can you share some updated links/books for a beginner?

Vitamin_Sushi• 5 years ago

Not op, but for me the official elixir site's guide help a lot. I actually read that side by side with Sasa Juric's Elixir in Action and felt like I got a pretty good understanding of elixir. For Phoenix, I've just been using the guide in phoenix's hexdocs and reading some random blogs about anything specific.

scns2• 5 years ago

I bookmarked this one from the last discussion of Phoenix on HN: https://sergiotapia.com/phoenix-160-liveview-esbuild-tailwin...

ch4s34• 5 years ago

For liveview there's Programming Phoenix LiveView[1]. The stuff on https://pragmaticstudio.com should also be up to date. You can also check out the newsletter http://elixirweekly.net.

[1] https://pragprog.com/titles/liveview/programming-phoenix-liv...

aloukissas2• 5 years ago

Chris: how do you feel about what's needed to make Phoenix as "core" of a technology like other similar projects like Django or Rails? The latter are used by huge companies, which have vested interest in keeping these technologies around and evolving. Is it corporate sponsorship from companies using Phoenix? Note, I've used Phoenix/Elixir as the core technology in the last of the 3 companies I've been in.

chrismccord5• 5 years ago

We're already there. We have huge companies using elixir and phoenix, with phoenix powering the web platform for the majority of them. Several great case studies exist on elixir-lang.org if you're interested, ie:

Pepsi: https://elixir-lang.org/blog/2021/04/02/marketing-and-sales-...

Heroku: https://elixir-lang.org/blog/2020/09/24/paas-with-elixir-at-...

Change.org https://elixir-lang.org/blog/2020/10/27/delivering-social-ch...

And of course Bleacher Report, which has been on Phoenix since 2014, well before 1.0.

On the sponsorship side, DockYard invested in my work for the last six years where I spent the majority of the year working on oss, and I've just joined https://fly.io where I'll spend 85% of my time working on Phoenix and related libraries. So we are well covered on the corporate sponsorship side. We also have Michael Crumm on the Phoenix team who works at Cargo Sense, where they support a portion of his time working on LiveView. Of course it would be great for other large companies leveraging value out of our work to give back, but we're well established on the sponsorship side :)

ipnon4• 5 years ago

Ruby companies like AirBNB, Stripe ended up edging out their competitors using the relatively glacial Java or C++ frameworks. We will need to see a new generation of Phoenix winners before Elixir is taken seriously.

It could be that the marginal performance gain from using Elixir is not worth the hassle of training and hiring in a whole new language. It remains to be seen.

whitepoplar• 5 years ago

Hey Chris! Is there a LiveView future where one can forego javascript frameworks altogether in creating higher-fidelity UIs?

yetanothermonk5• 5 years ago

Have you seen Surface UI? Pretty cool. Collection of LiveView components. https://surface-ui.org/

chrismccord5• 5 years ago

That's really the goal, and for a large class of applications we are already there. Higher-fidelity UIs is pretty vague and there is absolutely a limit to where you necessarily need a bunch of code running on the client. Google maps & docs? Millions of lines of JS is inescapable, but dashboards, feeds, chats? LiveView excels here. We don't yet know where the limit is, but if you look at Livebook, we have a collaborative code notebook with presence, realtime updates across users and operational-transform based content updates powered by LiveView, with only ~3k lines of basic JavaScript for the client-side bits like the Monaco editor.

subbu• 5 years ago

I rewrote a large Rails+React+GraphQL with LiveView. LiveView replaced most of React. I still use React for rich text editors and complex browser based UI. LiveView plays well with this. I am happy not using GraphQL at all. It also consolidated all MVC code in one place. Phoenix made a few other things possible: in place chat, live updates (via websockets. No more polling).

ecmascript• 5 years ago

Can you answer another, more personal question: How do you stay motivated and productive? What is your best tips?

I gotta say I am a huge fan and liveview is a game changer in many ways. Great work with Phoenix.

losvedir• 5 years ago

I've dabbled with Phoenix 1.6-dev (after seeing it in action and being mindblown in the livebook code), and think the new HEEX components are great.

Building a LiveView app out of components, and sending messages back to the server and re-rendering, feels a lot like building a react app! This is a real intuitive and easy to use flow. (I remember when react came on the scene and its "one way dataflow" was so groundbreaking to me.) That said, a react app where every state update is a round-trip to the server is probably not ideal. I know that there's the PETAL stack for this sort of thing. I guess my question is: with so much functionality available in pure Elixir/LiveView, what's your decision process when embarking on a new app about when to try to get by with just that, vs bringing in react or a full SPA frontend and simple API backend?

Separate question: what's the best dev environment and tooling for Elixir/Phoenix/LiveView these days? My VSCode setup is pretty great for React, particularly with format-on-save nesting and indenting my JSX properly. I miss that when working in (h)eex templates.

alberth2• 5 years ago

Hi Chris

Excited to see in this thread you joining fly.io

Can talk about what (if) any plans exist to make deploying Phoenix apps at fly easier.

Said another way, I’d love to click a button to deploy my app to be (a) globally distributed, (b) managed global database, (c) managed operating systems, (d) managed dns.

Basically heroku for Phoenix (and more)

mrkurt5• 5 years ago

Yes! What you're describing is important, and roughly matches what we want for all apps. Managing apps + databases across multiple regions should be as simple as `fly region add syd`. This takes like 5 steps right now, it should take one.

We're also improving the Phoenix deploy process. I don't like it when people have to see Dockerfiles. Modern app deployment needs frameworks and infrastructure to work together. Our Elixir deployment doc (https://fly.io/docs/getting-started/elixir/) will someday be replaced with, hopefully, "mix phx.deploy".

sergiotapia• 5 years ago

I like how Phoenix had the stones to replace webpack after all the additional support requests it was bringing in. I've been using esbuild with 1.6.0-dev and it is a lot more ergonomic for the end user dev - https://sergiotapia.com/phoenix-160-liveview-esbuild-tailwin...

What has me really excited was that I was looking at Fly.io to create a global mesh of servers for a liveview app so people can connect to whatever is closest, and guess who just joined Fly.io's team? Chris! I think this is going to be a very productive stack that will get you far far ahead of the competition once you learn it's patterns. Complicated features become trivial to implement with great UX to your customers.

generalk• 5 years ago

I've gotta agree. We replaced webpack with esbuild in our Phoenix 1.5 app. The migration took a bit of time to get right, and I was questioning whether it was worth it, but having seen the results -- faster builds, fewer dependencies, generally not having to worry about webpack at all -- I'm thrilled this is becoming the default.

ch4s34• 5 years ago

Yeah, fly.io seems like a great fit for many of Phoenix's use cases. I'm really excited to see how things shape up.

chimen• 5 years ago

"Phoenix 1.6 ships with a new phx.gen.auth command for a complete authentication solution bootstrapped into your application" - hope it's a decent implementation. Setting up a JWT authentication took me days while learning phoenix/elixir and it is the sole reason why I never went with Phoenix for any other project. So many components involved.

gustavohoa• 5 years ago

AFAIK, this solution is not for JWT auth. It's for session based auth.

yetanothermonk5• 5 years ago

It is very, very good. You can try it even without phoenix 1.6 as a hex package and it's great.

1_player• 5 years ago

What's the hex package? Can't find it.

rawoke083600• 5 years ago

Agreed ! My experience as well, otherwise Phoenix does looks very good yes.

yetanothermonk5• 5 years ago

Jose wrote the bulk of the code and he worked on Devise. Blog post (1yr old) from Jose here. https://dashbit.co/blog/a-new-authentication-solution-for-ph...

nickjj5• 5 years ago

Looks good.

In one of the HEEx examples in this post it mentions components and uses a weather component as an example with: <MyApp.Weather.city name="Kraków"/>

I'm curious, what would the syntax look like if you wanted to create something like a card component that has an optional header, body and footer where you would want your arguments to be blocks of arbitrary HTML that you pass in and not a single string variable?

Basically a way to do something like this (a more simplified version since I don't know what the API would be):

    <Foo name="bar">
        <p>Custom stuff!</p>
    </Foo>

And then the component itself would have a named "yield" that places in your arbitrary blocks of code in the correct spot.

I think this might be called slots in other frameworks, but they seem essential to be able to create re-usable components unless HEEx has an undocumented way to do this? It looks like Surface has this at https://surface-ui.org/slots.

What are the benefits of using HEEx over Surface? I know they're working together and in the end will share similar functionality and maybe Surface will use HEEx under the hood but as an end user building web applications with Phoenix is there a single case where I would use HEEx instead of Surface? If not, why isn't Surface part of core Phoenix or not heavily pushed as what to use for a templating solution in the docs?

lessthanseventy• 5 years ago

I think this might be what you are looking for: https://hexdocs.pm/phoenix_live_view/Phoenix.Component.html#...

nickjj5• 5 years ago

Thanks, I think that would very likely handle the basic case of having 1 block.

But in a re-usable card component you might decide to have a title, body and footer block where the footer is optional and perhaps falls back with a default value if it's undefined. Slots with Surface handle this use case based on their docs. I think there's a lot of component use cases where you'd want the idea of having multiple blocks.

The docs you linked don't cover if HEEx supports anything like that, or being able to use multiple named blocks in 1 component. I tried to read the source but render_block is a macro and I couldn't proceed to trace it.

ramchip• 5 years ago

Slots are on the heex roadmap: https://github.com/phoenixframework/phoenix_live_view/issues...

I chose to stick to base LiveView in my apps because it works fine (slots are nice but not essential), and I want to avoid too much API churn and learning curve for other devs on the same team. The best Surface features are being gradually refined and merged into LV. HEEx is a great example of that.

xutopia• 5 years ago

I'm loving the direction that Phoenix and Elixir is taking. I am well invested in my current company but one day if I get a chance to work with it professionally I will be very happy. The tooling is evolving at a quick pace and is super powerful already out of the box.

lostcolony2• 5 years ago

"Phoenix also now includes swoosh by default for mailer support and a new phx.gen.notifier task for generating a notifier for sending email along with a dev mailbox for local development."

Crap. I literally just built this out for a personal Phoenix project two weeks ago (using Bamboo instead of Swoosh because I could get it working for SES more easily). Guess I'll see about adopting the official and probably far better solution. Since there are also published upgrade steps. CURSE YOU FOR BEING SO HELPFUL, PHOENIX DEVS!

joerichsen• 5 years ago

Yesterday we launched a big feature built using Elixir/Phoenix/LiveView/Surface and it has been really great.

We are a SAAS for managing sports teams and clubs https://www.sportmember.com and our current stack is Ruby on Rails, GraphQL and React Native for our app.

When deciding to develop this new feature we narrowed it down to these two options:

1) Rails/GraphQL/React

2) Elixir and LiveView

What's great about Elixir and LiveView is

1) The whole GraphQL API layer was not necessary to build. The best API is no API ;-)

2) No need to duplicate code like for example for validation on the frontend and the backend

3) Developing the whole feature using just Elixir instead of having to switch between TypeScript and Ruby

This means that we have been able to develop this feature in about 2/3 of the time which is pretty nice!

aloukissas2• 5 years ago

Follow-up question: having built a mobile app backend on Phoenix (with Channels) and having played a bit with Absinthe and LiveView -- is there a future of Phoenix that's focused not only on web but also mobile?

Phoenix 1.6, RC0 released

Related Stories