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

Phoenix 1.7 is View-less

germanvelasco.com

Post reply on HN
Print view View original

181–190 of 224 posts

Re: Phoenix 1.7 is View-less

#181

Post by lnxg33k1 »

andrewmutz wrote: post #122
lnxg33k1 wrote: post #24

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…

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

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

Re: Phoenix 1.7 is View-less

#183

Post by ctvo »

throwawaymaths wrote: post #106
ctvo wrote: post #102

Earlier quoted context omitted.

> 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 oper…

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"

The abstractions I’m talking about are the Erlang VMs and the primitives like actors that are provided by the OTP. I have cold sweats thinking about needing to debug a non-obvious performance issue and diving into that layer.

Re: Phoenix 1.7 is View-less

#185

Post by sb8244 »

conradfr wrote: post #164
sb8244 wrote: post #131

Earlier quoted context omitted.

Correct. You could rig something up in probably 2-3 days if that was super important for you. I did manual typing at the edges and that sufficed for me.

Well yes, not sure why I got downvoted, if I use a language called TypeScript it may be because I think type checking is important. Having to call tsc separately from my dev/watch process is not a good developer experience. Same as with ... dialyzer :) But for sure, that would decimate esbuild performances.

I'm also not sure. I think it's an interesting point that you bring up.

My comment on value is mainly one of "all or nothing". I think a manual typing at the edge is probably sufficient for most people.

That said, you could implement all of your forms and events as structs or schemas and rig up a piece of the dev process to convert them into types. I think many in Elixir would view it as overkill so it hasn't been done afaik. But I also think it could be implemented very easily and then you'd have end to end typing.

Re: Phoenix 1.7 is View-less

#186

Post by sb8244 »

pbowyer wrote: post #150
sb8244 wrote: post #130

Earlier quoted context omitted.

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…

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.

Ranging from very basic static form to forms that had dynamic /polymorphic embedded objects in them. Like being able to hit a + button and a new row is added as a child of the form that has it's own validations based on a type attribute.

Re: Phoenix 1.7 is View-less

#187

Post by josevalim »

NhanH wrote: post #180
josevalim wrote: post #168

Earlier quoted context omitted.

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…

Is the plan to keep esbuild (and npm integration) for the long term, or would that be deprecated in a few years?

I would hope it to be long term but it is impossible to know given how fast the JS landscape can change.

But also keep in mind that Phoenix is not tied to any of these. The esbuild bits are only part of the generated app, which you can stick to or change altogether.

So when we moved to esbuild, we broke zero of the existing apps and no deprecations were emitted. The same would happen if we move away from esbuild.

As an example, I moved most of my apps to esbuild (and I have been very happy with it), but one still uses webpack because it uses the Monaco editor and we rely on certain plugins. So our approach has always been “sane defaults” but not getting in the way if you know better or prefer something else.

Re: Phoenix 1.7 is View-less

#188

Post by ch4s3 »

throwawaymaths wrote: post #138
ch4s3 wrote: post #123

Earlier quoted context omitted.

I hear this about big JS codebases but the 7 year old Elixir app I work on is many 10s of thousands of lines of code and we just don’t have that problem.

It's not nothing but it's rare. After about two years I finally had a type error. It wasn't horrible, though, just caused extra log lines.

It’s not that we never have type errors, it’s just that they’re the least frequent kind of error I see monitoring sentry. We try to do a zero exception policy, so we’re really on top of what kind of errors are happening.

Re: Phoenix 1.7 is View-less

#189

Post by mcmatterson »

eclark wrote: post #70
h0l0cube wrote: post #47

Earlier quoted context omitted.

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.

Bandit author here. We’re fully supported on phx 1.7+; it’s a one line change to your existing app, described on the Bandit readme!

Re: Phoenix 1.7 is View-less

#190

Post by mcmatterson »

eclark wrote: post #70
h0l0cube wrote: post #47

Earlier quoted context omitted.

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.

The PR you linked to adds support for generating new phx apps with the relevant change already incorporated; it’s just a generator change. We’re waiting a bit to incorporate this change to ‘soft launch’ Bandit support.
Post reply on HN