3 ms·
If you're asking why you got downvoted (i didn't downvote you), i think it's because of the weird phoenix/elixir vs react/js comparison, together with wondering
by bsaul 7y ago
If you're asking why you got downvoted (i didn't downvote you), i think it's because of the weird phoenix/elixir vs react/js comparison, together with wondering what nim brings to the table. It all seemed very confused, a bit like comparing apples to oranges. But that's just my opinion.
- abledon 7y agoI think when they compare phoenix/elixir to react/js maybe they are incorporating LiveView into the equation, as it allows SPA like ability through a backend LiveView template.
- xrd 7y agoThat makes sense. I wasn't attempting to compare these technologies at all. I was suggesting that when I look at a new technology, I like to think of what's there currently and then ask what this new stack brings that I can't already do with the existing stacks. Phoenix/Elixir seems like it permits solutions that might be 10x better than the existing solutions in that space. Agree 100% that this space I'm referring to is NOT Android. I was just attempting to explain how I make a decision to spend the time to understand a new stack and why I do or don't. Am I totally off base stating that Phoenix/Elixir is used in the same places React is? thoughbot wrote a piece about that: https://thoughtbot.com/blog/how-we-replaced-react-with-phoenix https://thoughtbot.com/blog/how-we-replaced-react-with-phoen... But, I'm curious why you think this is weird? Care to elaborate?
- bsaul 7y ago"Am I totally off base stating that Phoenix/Elixir is used in the same places React is?" There are so many things to consider when deciding upon an architecture that the choice of going SPA + "regular" backend tech (js, php, whatever) vs something as specific as phoenix + elixir + server side rendering is really not a matter of "react" or something else. A few questions you'll have to ask : what if you want to add a mobile GUI, will you want to keep rendering everything on the server ? How will you fetch the data ? Should the GUI (either mobile or web) work offline ? If you go mobile will you want to benefit from reusing react patterns ? Now purely on the server side, erlang VM is highly optimized for concurrency (and not so much at pure cpu), but elixir is also a very peculiar language. How will you recruit people ? Is your team used to functional programming ? Do you have the skills to go to C programming in case you need performance ? Then comes deployment. Will you plan on using OTP and actor-based architecture, for maximum availability ? Do you want to deploy on google cloud using kubernetes ? Heroku ? App-engine ? Each of these options have implications on your stack. etc, etc. I could go on forever. The post you mentionned only talked about the most basic thing every single tech has been able to do for the last 30 years, aka : render a web page from a template. But that's a very very narrow consideration for picking a tech stack.