[HN Gopher] Phoenix 1.7 is View-less
___________________________________________________________________
Phoenix 1.7 is View-less
Author : todsacerdoti
Score : 175 points
Date : 2022-12-30 18:52 UTC (4 hours ago)
(HTM) web link (www.germanvelasco.com)
(TXT) w3m dump (www.germanvelasco.com)
| rjh29 wrote:
| 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.
| tiffanyh wrote:
| 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 wrote:
| 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.
| travisgriggs wrote:
| 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. :(
| tiffanyh wrote:
| 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?
| h0l0cube wrote:
| 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
| tiffanyh wrote:
| > Actually, I think the next big unlock in user adoption
| is static typing.
|
| From reading that post, it sounds like Jose does _not_
| believe static typing is needed. But a nice to have to
| address a _very narrow_ set of use cases that primarily
| would help for documentation, not bug mitigation.
| h0l0cube wrote:
| I think that Jose makes a solid case that static typing
| doesn't bring as much to the table to Elixir as most
| people believe, but enough people point to the lack of it
| as a reason not to adopt the language that it's worth
| addressing. Again, I think @spec is great and people
| should use it more - just treat the dialyzer warnings as
| errors.
| ch4s3 wrote:
| 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?
| sodapopcan wrote:
| 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.
| gnutrino wrote:
| 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.
| freedomben wrote:
| 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_husky wrote:
| Yes, exactly like that.
| eclark wrote:
| 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
| thriftwy wrote:
| So did the MVC model just got stripped down to just C, a.k.a.
| Servlet but with more amenities?
| lnxg33k1 wrote:
| 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 wrote:
| > 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?
| lnxg33k1 wrote:
| 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
| freedomben wrote:
| 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.
| ealdent wrote:
| So can we refer to LiveView's counterpart as DeadView, now?
| sodapopcan wrote:
| We actually already do!
|
| I have no links but click around https://elixirforum.com and
| you'll see referencing "dead views" often enough.
| sergiotapia wrote:
| 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
| password4321 wrote:
| The downside as I understand it is the extra work to manage UX
| for connections with high latency and/or going offline,
| correct?
| freedomben wrote:
| 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_husky wrote:
| 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.
| sergiotapia wrote:
| 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.
| cultofmetatron wrote:
| > 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.
| benatkin wrote:
| 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 wrote:
| What is your point?
| benatkin wrote:
| Just to point out that "ZERO react/JS nonsense" is based on
| looking down on mainstream languages even after they've
| improved and even though the platforms use them.
| canadianfella wrote:
| [dead]
| buzzerbetrayed wrote:
| It sounds like you've never used Liveview to me. There
| are many advantages to it besides just zero JS.
| sergiotapia wrote:
| I've used them enough to have my own informed opinion on
| the languages, frameworks and mentality in the ecosystems
| I talk about. We're both right -- because we both are
| sharing our opinions.
| davidatbu wrote:
| 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/
| ch4s3 wrote:
| You can use gleam in an application that uses Phoenix for web
| plumbing pretty easily.
| [deleted]
| eclark wrote:
| 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.
| Mizza wrote:
| 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.
| tiffanyh wrote:
| 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.
| eclark wrote:
| 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.
| tiffanyh wrote:
| @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.
| h0l0cube wrote:
| 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
| tiffanyh wrote:
| That's a great point and Phoenix 1.7 is the first release
| to support the usage of other web servers
| eddsh1994 wrote:
| 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 :)
| eclark wrote:
| 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.
| drannex wrote:
| This definitely reduces some of the cognitive overhead of
| designing out a Pheonix service, thats for sure. A really welcome
| change in my eyes.
| dooven wrote:
| 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.
| tobyhinloopen wrote:
| So many great changes! I can't wait!
|
| I've been using Phoenix / Elixir since 2016 and i've been really
| happy with it
| Crazyontap wrote:
| 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 wrote:
| livewire was inspired by liveview. I think livewire 3 will be
| more like the newer version of liveview
| bnt wrote:
| Well, unless it moves completely to Websockets, it will still
| remain a slow mess.
| jnsaff2 wrote:
| I think livewire was inspired by phoenix liveview. I remember
| there was even a podcast interview about it.
| cultofmetatron wrote:
| 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.
| freedomben wrote:
| Yes, there are a lot of similarities. As mentioned in siblings,
| Livewire was inspired by LiveView so they are directly related.
| metaltyphoon wrote:
| Pig backing here... is this like Blazor server-side?
| ch4s3 wrote:
| Yes, Blazor is inspired by LiveView.
| oDot wrote:
| People using Phoenix Liveview -- how do you serve native apps
| relying on the same backend?
| sergiotapia wrote:
| I use Absinthe to expose a graphql API endpoint.
|
| The Absinthe resolvers just call the contexts/functions my
| liveviews call anyways.
| sodapopcan wrote:
| 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_husky wrote:
| 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.
| Alacart wrote:
| 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.
___________________________________________________________________
(page generated 2022-12-30 23:00 UTC)