Live data from Hacker News

Phoenix 1.6, RC0 released

phoenixframework.org

61–62 of 62 posts

Re: Phoenix 1.6, RC0 released

#61
post #19

Earlier quoted context omitted.

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.

I am really confused by this comment. "Companies leveraging a quick to develop in, batteries included framework, with really poor performance, beat out companies using highly performant but less quick to develop in languages/frameworks, is reason why I'm suspect about a quick to develop in, batteries included framework that also prioritizes real time communication, with quite solid performance, and really predictable…

> Will Phoenix penetrate as broadly as Rails? Probably not, since Rails already exists

I hope it does one day, but not to replace Rails.

It's a really hard sell because I think eventually we're all going to converge to the same real-time, low server cost setups. At this point it becomes how fast is it to build my app and what is it like to maintain it.

Rails 7 is coming out with a neat feature that will build in encrypted fields at the DB level for Active Record with a way to situationally decrypt them in case you need to debug something specific in production. Then, any time a developer accesses those decrypted fields an audit log will be generated. It'll also audit log any Rails console access[0].

These are really big things to not have to deal with. Will Ecto ever get this sort of thing? Maybe, maybe not. But I think the bar is raising overall where if things like this aren't added in the future you have a less chance of being adopted by the masses because not everyone has the resources to spend months developing stuff like this in house.

Did we exist without it in the past? Absolutely, but I think we need to be comfortable with adjusting our expectations that higher standards are coming as there's more framework competition and languages coming out. LiveView is a great example of this, only a few months after it was announced a bunch of popular frameworks released their take on it that play to the strengths of that framework of choice. Now there's kind of an expectation that it shouldn't take an SPA to develop a mostly document driven application with a nice user experience.

Personally I would want features that help me build apps faster and more securely while having to pay $40 / month to host my app instead of a framework that doesn't have these features but it costs me $20 / month to host it instead. Sure if you take this to completion and say but if you have 10,000 servers running it's double the cost but for most applications you can host a pretty popular and profitable app for less than $100 / month with any modern tech stack without making performance compromises (ie. [0]: https://twitter.com/gregnavis/status/1431149713470930944

Re: Phoenix 1.6, RC0 released

#62
post #28

Looks good. In one of the HEEx examples in this post it mentions components and uses a weather component as an example with: 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…

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.

Post reply on HN