Phoenix as a Meteor alternative

Except I have nothing to do with Phoenix. I’ve used Meteor for about a year, made projects with it, created and contributed to some packages (you can see my gh profile), promoted Meteor and helped a lot of people with examples. The last thing I was building - reusable admin packages for Meteor for faster rapid development. I made a working beta version with Blaze and an app for a friend on top of it, but then news about React, new modules system, etc.

I simply can’t rebuild everything every 1-3 months with no clear roadmap. I did find some talks in different posts about Phoenix during the last month, decided to give it a try and actually liked, how easy working with Phoenix is and how many possibilities and power now I have.

I will be really happy, when Meteor will be stable in future with strong convention and probably LTS support so that I can give it another try in future projects.

6 Likes

It’s clear that some people are very opinionated, and have a very feigned way of wording things. Maybe it’s from not being native english speakers. Newer frameworks are interesting, but I agree with you that their case would be much better served arguing over actual code. At least remove some of the blanket from the statements about what can or can’t be done.

Why is it reasonable to think that Phoenix will be stabler, have better LTS, etc, when it reaches Meteor-like size and maturity? Because of hype, taglines and buzzwords? Or is there any tangible difference to the approach Phoenix is taking, compared to a project like Meteor? You would have to make it a fair comparison. Not compare it to Meteor of today('s environment). Any fast-moving project, especially as it becomes bigger, will have to manage deprecation properly. Look at React. Meteor is no different. If your project has to be rebuilt every 1-3 months (seems generous on your part, if you’re referring to Meteor releases) it probably isn’t because Meteor’s unstable, or doesn’t have good LTS. And if it is, make and expect uproar and a bugfix. If it (feels like it) HAS to be rebuilt that often, it’s probably because you want what’s being offered by a new release, or by novel approaches around the framework.

2 Likes

I apologize if I offended you by something I said (I suspect this from reading comments further down) as that was not my intent at all. I guess that could have been a loaded statement, but is it not true? If you are going to build a serious mobile app you pretty much need to build a meteor app specifically for that purpose. You can’t turn an existing large web application into a mobile app without a lot of work. My point was simply that Cordova integration isn’t much of a win for web apps when you have to rewrite a lot of your app to even use it. You might as well go the React Native route.

I’d love to know what people are doing to make 1.2 load faster (if it’s even happening). I remember that Slava, who previously worked at MDG, stated in the forums that he dropped his load time significantly prior to the 1.2 release. However, I hang out in the Meteor Club slack and just yesterday some of the heavy-hitters in the Meteor world were talking about slow load times so I suspect that there isn’t anyone doing it successfully if they aren’t able to pull it off.

I agree. It’s incredibly insulting to tell someone that they are a scrub just because they use some framework. I apologize if my comments insinuated that in any way.

I’ve worked on a couple projects that simulate pretty much everything Meteor has to offer with React/Redux on top of Phoenix. This last weekend I spent some time integrating it with RethinkDB and that worked out really well. I’m actually pretty stoked about it. That said, @SkinnyGeek1010 likely has more to show in the “Show me the money” arena. He’s got a production app running React/Redux + Phoenix + RethinkDB and said it’s pretty much worked flawlessly. Have you taken a look at RethinkDB? Pretty cool stuff.

Haha not at all. Although I can see how you’d think that. I think people just get super excited about new tech in our world and can sometimes be VERY LOUD about their feelings. At least we aren’t blowing up Twitter right? :wink:

I’m sorry if this is how you really feel. I wish I was calculating enough to opportunistically take advantage of the holidays to push an agenda. Unfortunately, I am but a mere mortal and don’t think too far ahead. That said, I do think a number of earlier posts in this thread speak to the “our framework stands on its own merits to solve a specific class of problems” comment. You mentioned earlier that Phoenix is on your list of tech to learn about so I’m sure you’ll see the benefits when you get around to playing with it.

Although I’m not the author of this thread, I think it’s fair to say that it wasn’t started to initiate a pissing match. Meteor and Phoenix are both good frameworks and I use both currently. My intent in commenting here is to advocate for developers to learn new things because I think it helps you in whatever you are doing.

7 Likes

Here is a playlist of a google group working their way through the book a chapter at a time over the past month.

At around 10m in the first video there is a discussion showing how to skip the view/template components when rendering JSON for an api. I know that was asked earlier in the thread.

This thread was created specifically to consolidate all the Phoenix buzz into one place. Nobody is forcing you to click on it.

If you wish, we could easily go back to spamming ‘just use phoenix’ across multiple threads when someone discovers Meteor’s inability to scale due to oplog tailing or wonders why sql support has been on the roadmap for a year now.

3 Likes

Cool, i’ll have to watch that video later! I think there’s a lot to gain by comparing notes with other readers.

I’ve found the JSON views to be really helpful with munging data (viewable by using the mix phoenix.gen.json Post posts desc:string and then look in the views folder)

I had no idea those book clubs were going on! haha. Michael Ries lives right by me and spoke at our local Elixir Meetup a couple months ago. He’s a nice guy. Thanks for sharing!

1 Like

Can we not start a @ryanswapp ‘blog post club’ or @SkinnyGeek1010 ‘blog post club’ and start a hangout thread to share ideas & what not ? It would be awesome.

I vehemently disagreed a month ago in the whats-wrong-with-blaze thread . But then @jacobin said something gold - Time is better spent learning React . I really liked that motto and abstained from further taking part in these arguments and learnt React :smiley: instead. Although I miss the blazing fast mvp-making speed, I believe I will come up to speed with React soon as its more of a thinking pattern rather than syntax.

Finally, @SkinnyGeek1010 was talking about various programming languages in various threads and I really liked that. I liked how he advocated learning from other Languages and implanting it in javaScript. I always wanted to learn a side language for fun. Either Python, Clojure or Elm was on my list but then I learned about Elixir & Phoenix from you all. I have been hooked since to be honest. Its hard not to look at those youtube videos. I won’t use it in my main project, but the distributed data system has definitely made me interested.

8 Likes

Once you learn one c syntax derived language you really have learned them all. You know ansi-c you will be able to read java. You know java you know C#. Javascript, well by then you know it kind of sucks.

Elixir necessitates a different perspective and thinking pattern. I was resistant at first when @SkinnyGeek1010 was championing functional programming. However the change really is not as drastic as you might think.

Lambdas are just anonymous methods.
Chaining functions are just unix pipes.
Pattern matching is just akin to interface overrides.

Turned out I know how to do most all this FP stuff already. It looks strange but can do some really wild stuff. Sort of like the girlfriend of that guy in a Lumberjack costume over at the coffee house.

3 Likes

Haha! Got a good laugh out of that one.

Come on over to the Elixir slack channel! We’ve got a meteor-dev channel where we toss around ideas :wink:

3 Likes

Were’s that slack channel? Any idea on how can I use Phoenix as a chat backend and connect it to meteor publications? That seems like a really good option for me. Meteor + Phoenix. And what’s the best db option with Phoenix for that? (Lots of small writes)

Here is the slack channel https://elixir-slackin.herokuapp.com/

I haven’t ever tried to hook Meteor into Phoenix, nor have I thought much about it, so anything I say is just an off-the-top-of-my-head comment. @SkinnyGeek1010 has done it though so he likely has a good idea of whether that’s possible.

There is no best DB option for anything really. It comes down to your project needs. Phoenix defaults to Postgres which is a really solid option. I also think RethinkDB is a stellar choice so you likely can’t go wrong with either of those.

2 Likes

This is super interesting… But I’m thinking of holding off building a phoenix/redux app at the moment because this issue https://github.com/facebook/relay/issues/114 is going to be resolved at some point.

I think relay will completely replace redux as soon as it can handle both client and server data.

And then there’s this issue: https://github.com/facebook/relay/issues/541 that is trying to cover real-time updates via subscriptions.

Once relay matures a bit more in company with Elixir’s graphql packages, that will an incredible way to build apps going forward.

I don’t know much about Relay, but from a quick glance it looks intriguing. When school calms down I’ll have to give it a closer look.

Ya I agree! Chris McCord has been saying that their goal is to move Phoenix over to a more GraphQL type system so that should definitely be interesting. He and Jose are super smart dudes. They seem to be pumping out good stuff at a break neck pace! Pretty impressive.

Chapter 9 on Phoenix Channels was uploaded tonight. Disappointed you were not there.

Do you have some thoughts about this other solution that tries to compensate Meteor limitations, mainly about scaling, but still using Node.js?

It seems well done.

1 Like

It’s a great proof of concept. I wouldn’t say scaling is the main issue he’s attempting to resolve. He’s put a lot of thought into many aspects.

The project looks interesting, but with only 34 commits from one guy it’s too early to tell what will become of it. I hope others start pushing code.

It’s certainly a direction MDG should be heading towards but will never be able to. The level of resistance to positive change in the meteor community dwarfs that of when Apple decided to ditch Motorola.

Myself though, Elixir has re-ignited my love for programming. Whenever I write code in Javascript I feel dirty. It is so bad on so many levels. That and the fact that Phoenix’s development activity level makes Meteor look like abandonware in comparison.

3 Likes

I’m confused as to why Phoenix is a suitable Meteor alternative tbh. I’m always interested in new technology and do have a habit of jumping from framework to framework - but Phoenix is a backend-only framework written in an obtuse (albeit seemingly enjoyable to use) language. It’s hardly like you could jump from one to the other.

I’m not sure what I’m getting at really, but I can see why @Babak is a bit fazed. There’s more activity in this thread than in Elixir’s SO tag.

2 Likes

I guess my tolerance for mucking around in javascript is a bit higher :smile:

Honestly, with babel, there is rarely a pattern that makes me feel dirty. And the beauty of a language that updates annually is that it keeps getting more performant & it’ll probably absorb some good parts of Elixir, too.

I don’t think there’s an inherent performance gain to Elixir (the one benchmark is outdated, was performed on different machines, and didn’t really test much). We’ve all heard the success stories of node in Netflix & Walmart black fridays, but they don’t use sockets like we use them. About a year ago someone forked node to work concurrently, it never got popular because evented programming is just as fast & easier to reason about.

There’s always something to learn from a different language. Evented programming didn’t start with node, the libuv pattern was popular in C/C++ since the 80s. Chances are Flux/Redux wouldn’t exist without Elm & that’s a functional language. Who knows what nice treats the JS community can steal from Elixir :wink:

3 Likes

I know… I even talked to Michael about! Hopefully I’ll be on the next one. It’s been a little hard making the time with school :frowning: