Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Phoenix LiveView 1.2

phoenixframework.org

Post reply on HN
Print view View original

11–20 of 62 posts

Re: Phoenix LiveView 1.2

#11

Post by rubyn00bie »

I’m not sure how I feel about the CSS integration. Nor the collocated JS that was somewhat recently released.

On one hand, yes it is convenient, but on the other it could become a huge mess. It reminds me of Rails 2.x where it became almost impossible to debug, or fix front end code that used rjs or whatever it was called. Because disparate snippets of JS were littered throughout your code base in files that were hard to find.

I’m sure the Phoenix team has put a lot of effort into it, and I truly hope it slaps. I myself am just really hesitant to use it, when CSS files and non colocated JS work just fine. I’ll probably be waiting a couple years before giving it a try

Re: Phoenix LiveView 1.2

#12

Post by rubyn00bie »

cpursley wrote: post #10
rubyn00bie wrote: post #9

Earlier quoted context omitted.

TLDR; LiveView is web only. There have been efforts to make LiveView native, but it’s extremely difficult to do so, and thus far (to my knowledge) all have failed. I was thinking about this the other day because carsandbids (Doug DeMuro’s car auction site) uses Blazor (at least as far as I can tell). And I think that’s one of its biggest advantages of Blazor—- is that it is capable of producing native apps and web ap…

Why not just build mobile apps in their native language (Swift etc)? Anyways, end users absolutely notice and care - cross platform mobile apps are all hot garbage without exception.

That’s what I would do that personally. I hate wrappers around native SDKs. But I also learned them.

A lot of folks assume mobile apps are “difficult” because of the underlying language. But it’s not the language that’s an issue, it’s the SDKs. They’re so wildly different from each other, and the way things work on the web, that it’s (IMHO) a losing proposition to do so.

That’s not to say things like Blazor or React Native don’t have a place but that place is one that’s inherently difficult to maintain without huge amounts of ongoing effort and capital invested in non user facing features.

Re: Phoenix LiveView 1.2

#13

Post by Tinkeringz »

cpursley wrote: post #2

LiveView is such a breath of fresh air, especially over the vibe coded NextJS rats nests that have become the norm (that need specialized hosting, are dog slow and require a ton of proprietary paid services bolted on like caching, background workers and even auth which Elixir and Phoenix provide out of the box). https://elixirisallyouneed.dev

What caching is provided out of the box for Phoenix framework?

Re: Phoenix LiveView 1.2

#14

Post by conradfr »

Tinkeringz wrote: post #13
cpursley wrote: post #2

LiveView is such a breath of fresh air, especially over the vibe coded NextJS rats nests that have become the norm (that need specialized hosting, are dog slow and require a ton of proprietary paid services bolted on like caching, background workers and even auth which Elixir and Phoenix provide out of the box). https://elixirisallyouneed.dev

What caching is provided out of the box for Phoenix framework?

Doesn't seem to be mentioned in the page but if you're talking about request caching there's libraries like PlugHTTPCache or RequestCache.

Otherwise I usually use Nebulex (annotations are nice for Ecto queries) with ETS as it's faster than with Redis (if you don't care about losing the cache on deployment).

Re: Phoenix LiveView 1.2

#15

Post by [deleted] »

cpursley wrote: post #10
rubyn00bie wrote: post #9

Earlier quoted context omitted.

TLDR; LiveView is web only. There have been efforts to make LiveView native, but it’s extremely difficult to do so, and thus far (to my knowledge) all have failed. I was thinking about this the other day because carsandbids (Doug DeMuro’s car auction site) uses Blazor (at least as far as I can tell). And I think that’s one of its biggest advantages of Blazor—- is that it is capable of producing native apps and web ap…

Why not just build mobile apps in their native language (Swift etc)? Anyways, end users absolutely notice and care - cross platform mobile apps are all hot garbage without exception.

[deleted]

Re: Phoenix LiveView 1.2

#16

Post by epolanski »

cpursley wrote: post #10
rubyn00bie wrote: post #9

Earlier quoted context omitted.

TLDR; LiveView is web only. There have been efforts to make LiveView native, but it’s extremely difficult to do so, and thus far (to my knowledge) all have failed. I was thinking about this the other day because carsandbids (Doug DeMuro’s car auction site) uses Blazor (at least as far as I can tell). And I think that’s one of its biggest advantages of Blazor—- is that it is capable of producing native apps and web ap…

Why not just build mobile apps in their native language (Swift etc)? Anyways, end users absolutely notice and care - cross platform mobile apps are all hot garbage without exception.

Especially now that you can likely throw the mobile conversion to an LLM and judge the feasibility of it's maintenance once it's done.

Re: Phoenix LiveView 1.2

#17

Post by conradfr »

rubyn00bie wrote: post #11

I’m not sure how I feel about the CSS integration. Nor the collocated JS that was somewhat recently released. On one hand, yes it is convenient, but on the other it could become a huge mess. It reminds me of Rails 2.x where it became almost impossible to debug, or fix front end code that used rjs or whatever it was called. Because disparate snippets of JS were littered throughout your code base in files that were har…

To be honest that's copied from the JS frameworks. I tend to agree with you but sometimes scoped CSS is nice to have.

Re: Phoenix LiveView 1.2

#18

Post by cyberpunk »

rubyn00bie wrote: post #9
candl wrote: post #3

What are the pros and cons compared to ASP.Net/Blazor?

TLDR; LiveView is web only. There have been efforts to make LiveView native, but it’s extremely difficult to do so, and thus far (to my knowledge) all have failed. I was thinking about this the other day because carsandbids (Doug DeMuro’s car auction site) uses Blazor (at least as far as I can tell). And I think that’s one of its biggest advantages of Blazor—- is that it is capable of producing native apps and web ap…

I am a fan of the idea, but the websocket is also quite a big attack surface; you can do a lot more by sending messages over this socket to your phoenix app than you would likely expect to have exposed via some api on another framework.

It’s difficult to secure, in my opinion. Perhaps not impossible but the cost of doing so pretty much eclipses the benefits of using liveview imo.

Re: Phoenix LiveView 1.2

#19

Post by AdamConwayIE »

cpursley wrote: post #2

LiveView is such a breath of fresh air, especially over the vibe coded NextJS rats nests that have become the norm (that need specialized hosting, are dog slow and require a ton of proprietary paid services bolted on like caching, background workers and even auth which Elixir and Phoenix provide out of the box). https://elixirisallyouneed.dev

I've been loving LiveView. Been using it for a project for a client recently and it's so... chill. I like it a lot.

Re: Phoenix LiveView 1.2

#20

Post by mcintyre1994 »

cyberpunk wrote: post #18
rubyn00bie wrote: post #9

Earlier quoted context omitted.

TLDR; LiveView is web only. There have been efforts to make LiveView native, but it’s extremely difficult to do so, and thus far (to my knowledge) all have failed. I was thinking about this the other day because carsandbids (Doug DeMuro’s car auction site) uses Blazor (at least as far as I can tell). And I think that’s one of its biggest advantages of Blazor—- is that it is capable of producing native apps and web ap…

I am a fan of the idea, but the websocket is also quite a big attack surface; you can do a lot more by sending messages over this socket to your phoenix app than you would likely expect to have exposed via some api on another framework. It’s difficult to secure, in my opinion. Perhaps not impossible but the cost of doing so pretty much eclipses the benefits of using liveview imo.

I haven’t used it for anything in production so I haven’t seen these issues, could you give a bit more detail? I’m mostly wondering why you’d have any more websocket messages that you respond to than you would APIs if you were using any other approach. Does LiveView itself respond to certain messages bypassing your app?
Post reply on HN