Our great sponsors
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
-
Laravel
Laravel is a web application framework with expressive, elegant syntax. We’ve already laid the foundation for your next big idea — freeing you to create without sweating the small things.
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
-
-
phoenix
Phoenix is a self-custodial Bitcoin wallet using Lightning to send/receive payments. (by ACINQ)
-
https://pragprog.com/titles/liveview/programming-phoenix-liv...
Still in beta, but pretty up to date. Even in beta form, I thought it was pretty valuable!
simple solution: store the geohashes and compare prefixes, each prefix length is equivalent to a distance.
https://en.wikipedia.org/wiki/Geohash#Digits_and_precision_i...
or use one of the many geo libraries, like this one
https://github.com/yltsrc/geocalc
If I recall correctly, if some node desyncs, it's hard to get it started again. You have to manually transfer the entire database from another node which can obviously take a long time if you have a large database. It doesn't really handle netsplits by itself (there's https://github.com/uwiger/unsplit) so you have to be prepared to do this yourself.
I don't think there is a definite answer for "what a property designed framework" is but I can try to explain where Phoenix sits in the possible trade-offs.
One possible approach frameworks use to provide escape hatches is configuration. You ship with a series of defaults and, once you want to change it, you need to find out the proper knob to turn. A downside of this approach is finding the proper knobs when you need to tweak it.
Another approach is code generation: you generate code (or configuration) and keep the knobs clear to user. There are still defaults (and conventions) but the knobs are laid out upfront in your application. The downside here is that having so many knobs upfront may seen daunting or noisy.
Since you mentioned Rails, I will provide references on how Rails and Phoenix use those.
Both frameworks leverage both techniques above, but Phoenix errs more on code generation and Rails more on configuration. Here is a practical example.
Rails has a middleware stack that is part of all applications. This stack is hidden from you. Here is how the generator file for said application looks like:
https://github.com/rails/rails/blob/d0d9e8e576b06c19f8507510...
Phoenix has a similar stack (called plug) and the default stack is part of your application. Here is the generator file for it (it is not part of your app but used to generate it):
https://github.com/phoenixframework/phoenix/blob/3c27a34c27c...
You can look at these approaches and try to compare the pros and cons.
---
My biased opinion: I have worked with both and I prefer the Phoenix approach. I understand someone may find having all steps in your endpoint noisy or daunting, but the plus side is that it takes a glance to see all steps a request goes through and you can tweak it in any way you want.
When comparing to Rails, if you want to insert a middleware in the middle of the default stack, you need to explicitly say before or after which middleware. If you want remove something, you need to state the negation and say "I don't want to have this". Overtime this makes it hard for you to visualize what your application does, because you need to assemble the pieces in your head and use tools to print the stack for you.
This also matters on releasing new framework versions. Because Rails has its own stack, if it changes the default middleware stack in any way, it can slightly change how your code. What if the middleware you were inserting before was moved up? Or removed altogether? Or maybe a middleware you deleted was replaced by another one, with similar functionality. Do you want to remove it too? This can lead to subtle differences of behaviour when upgrading.
The code generation approach requires you to opt-in to the new features, which is, IMO, one of the reasons why Phoenix could avoid breaking changes in the last 8 years or so.
This is in no way a knock on Rails. I am 100% confident the Rails team is aware of those trade-offs and could equally argue for their choices. It also isn't a binary choice either, both frameworks use both approaches, with some general preferences for one over the other.
I don't think there is a definite answer for "what a property designed framework" is but I can try to explain where Phoenix sits in the possible trade-offs.
One possible approach frameworks use to provide escape hatches is configuration. You ship with a series of defaults and, once you want to change it, you need to find out the proper knob to turn. A downside of this approach is finding the proper knobs when you need to tweak it.
Another approach is code generation: you generate code (or configuration) and keep the knobs clear to user. There are still defaults (and conventions) but the knobs are laid out upfront in your application. The downside here is that having so many knobs upfront may seen daunting or noisy.
Since you mentioned Rails, I will provide references on how Rails and Phoenix use those.
Both frameworks leverage both techniques above, but Phoenix errs more on code generation and Rails more on configuration. Here is a practical example.
Rails has a middleware stack that is part of all applications. This stack is hidden from you. Here is how the generator file for said application looks like:
https://github.com/rails/rails/blob/d0d9e8e576b06c19f8507510...
Phoenix has a similar stack (called plug) and the default stack is part of your application. Here is the generator file for it (it is not part of your app but used to generate it):
https://github.com/phoenixframework/phoenix/blob/3c27a34c27c...
You can look at these approaches and try to compare the pros and cons.
---
My biased opinion: I have worked with both and I prefer the Phoenix approach. I understand someone may find having all steps in your endpoint noisy or daunting, but the plus side is that it takes a glance to see all steps a request goes through and you can tweak it in any way you want.
When comparing to Rails, if you want to insert a middleware in the middle of the default stack, you need to explicitly say before or after which middleware. If you want remove something, you need to state the negation and say "I don't want to have this". Overtime this makes it hard for you to visualize what your application does, because you need to assemble the pieces in your head and use tools to print the stack for you.
This also matters on releasing new framework versions. Because Rails has its own stack, if it changes the default middleware stack in any way, it can slightly change how your code. What if the middleware you were inserting before was moved up? Or removed altogether? Or maybe a middleware you deleted was replaced by another one, with similar functionality. Do you want to remove it too? This can lead to subtle differences of behaviour when upgrading.
The code generation approach requires you to opt-in to the new features, which is, IMO, one of the reasons why Phoenix could avoid breaking changes in the last 8 years or so.
This is in no way a knock on Rails. I am 100% confident the Rails team is aware of those trade-offs and could equally argue for their choices. It also isn't a binary choice either, both frameworks use both approaches, with some general preferences for one over the other.
Feel free to take a look at the package manager and let me know if there are any libraries that you need that are missing. https://hex.pm/
I can assure you I'm not spending my time inventing new libraries. In the past 3 or so years of working in Elixir there have been maybe 2 or 3 cases where I was looking for a library and couldn't find a suitable one. Writing my own code to cover those cases took a few hours. This should hardly be a deal breaker for anyone if you take into account dozens, maybe even hundreds of hours the ecosystem could save you in the long run if your project is a good fit for it.
I find that a large Elixir codebase is easier to work with than a larger Ruby or JavaScript codebase, but it still has the same difficulties to some degree.
If you're a typing fan as I am, and you are interested in the BEAM then you may want to check out [Gleam, a sibling language of Elixir](https://github.com/gleam-lang/gleam/) which has an Elm/OCaml/F# style static type system. It provides many of the strengths of Elixir but with that statically typed programming style which you may prefer.
(disclosure: I'm the lead dev!)
I came here because I thought this was about the app called Phoenix.
I was wrong.
Still, Phoenix deserves some love as well: https://phoenix.acinq.co/
> "different" platform with it's own unique patterns and quirks
Everything OP listed was a criticism directed at LiveView, the 'Live App' functionality, not Phoenix, the web framework. Live Apps are not exclusive to Phoenix either, as there are now imitators for every other web framework now, which at least speaks to its broader appeal amongst developers. So the criticism could be leveled towards the far less mature 'Live App' libraries on PHP/Python/JS/C# and so on and on:
https://github.com/liveviews/liveviews
Related posts
- Top 12 PHP Frameworks For Web Development in 2024
- Drupal 10.1 On OpenBSD 7.3: Install with Composer
- 30 Best Web Development Frameworks for 2023: A Comprehensive Guide
- Autoloading, coding standards and file structure in WordPress plugin development
- Strategic options for plugin system in a Synfony app?