Meteor is great for novices to jump in and start prototyping. After some time you will see the cost:
one database (huge deal for many of us)
poor build system (restricted with slow build time, can’t even compare to webpack)
poor package system (atmosphere is a mess already, with new blaze and modules things will get worse)
all js is loaded on first load
need’s a lot of server resources to handle small amount of users
almost no communication with core team
the time you spend on googling / reading forums on topics like “what router?”, “what view layer?”, “oh, deprecated?”, “new module system?”, “new data layer?”, etc is huge compared to the time you write your app
Core team reinvents the wheel all the time (build system, blaze with react core, etc) and doesn’t spend time on the things, community needs (new db’s, ssr, incremental loading, etc).
All in all, Meteor is great for novices, who want to try isomorphic js, but is awful for normal / advanced devs. The Webpack + React + Redux + Phoenix combo beats Meteor in everything, doesn’t restrict you and offers a lot more possibilities.
We make prototypes all day and they close deals. Then we turn that into a working app at minimal cost. Once a project gets big, then the best tools will be evaluated on their merits on a case by case basis. Rewrites aren’t a bad idea at all. Any project that is undergoing rapid growth and focusing itself on its proper market will have various directions left over in classes, functions, etc.
When your entity finds its voice a rewrite to shed its weight and make it efficient is justified.
Some people made claims that Meteor 1.2 loads for them faster than Webpack. I’m just calling for them to expound on their setup, this isn’t a holy war.
Babak
< 1m
I’m on a phone right now and that was the lamest diversion from backing yourself.
Percolate did this demo
Dynamically switches from SSR/SPA, has latency compensation, etc. Redo this app without compromise in Pheonix so you’re not just pulling arbitrary claims out of thin air. Link the GitHub and a quick way to get it running, as easy as above.
If not, clearly there are disadvantages to Pheonix as with anything under the sun, including Meteor.
PS – had a chat with someone at MDG about this and it will be much easier to start projects with the same SSR/SPA advantages soon. Win.
If you need, you can easily redo this app with Phoenix and compare it to Meteor. I never understood this marketing todo apps without even a router. You have such apps? Great, but I don’t have such simple apps.
This is totally your choice, what language or framework to use, I am here not to convince you.
Irrelevant response. I can redo it all in Ocaml and Oracle. Whatever. Of course. So what.
I’m saying put your money where your mouth is and redo SSR/SPA functionality as well as the various Meteor advantages including simulation, optimistic UI, etc, in Pheonix or move along.
Really just asking. Do you guys have an agenda to push Phoenix like undercover car salesmen chatting with customers at the competing dealership across the street?
Honestly, I think that the leaderboard or todo app example is making more harm than good to the meteor marketing.
There is absolutely no structure, how can people even understand the flow or the different parts of the framework with an example like that ?
Why they don’t create separate files, folders, give a proper structure so people will at least know the different parts.
@Babak, you feel very offended by this discussion, are you maybe one of the investors that is afraid of losing his money because people are talking about an alternative ? But you’re very funny haha, especially your way of spelling Phoenix ;).
I will tell you why I’m interested in Phoenix, even if I didn’t test it yet:
It has all the necessary tools and structure that a respectable full featured web framework should have: Router, Controllers, ORM, models with validation, tests and a lot more.
It uses an interesting programming language that is based on some interesting paradigms and runs on a battle tested technology that is also very performant.
It lets me separate concerns, I never liked all those ‘‘javascript everywhere’’ arguments, a good developer should be polyglot. Knowing or even mastering only javascript is not something that people can be proud of…
It is opiniated, and I think that opiniated frameworks that follow some kind of standard and structure are better for teamwork and for the industry (that’s also why I liked Meteor compared to other JS frameworks, because it has some kind of structure and that I can hop in any well written Meteor app and understand it quickly).
Just tired of this stupid post on this forum. I was made aware of Phoenix and have it on my list of tech to checkout but I’m turned off by the pushy sales-like bullshit and the corny ad hominem attacks.
A while ago I brought up Phoenix as a way to try and learn from how they accomplish real-time with pub/sub instead of livequery (which also eliminates the db issues). Since then i’ve used it to eliminate an oplog bottleneck in one of my apps that had unexpected growth (by basically using side-by-side along with the Meteor app).
However, the rest of the apps i’ve made do not need Phoenix and Meteor works just fine. In fact i’m (mostly) happily using Meteor with Webpack.
I also personally try not to sell Phoenix over Meteor as I view them as two very different things. As I mentioned earlier Meteor does a lot of things much better than Phoenix.
I also find it distasteful that people poke fun at @Babak misspelling Phoenix, it’s very easy to slip up when typing. I’ve done it, you’ve done it, Get over it. Phoenix is not clearly better than Meteor. If this thread starts to get hostile i’m leaving it.
However, I do think it’s a wonderful framework/lang to learn as it will help you write better JavaScript/Meteor code. I’m currently working on finishing up a REST router for Meteor based on my learnings at it’s much easier to test/maintain that current solutions.
As long as they contain Meteor-specific functionality to some meaningful extent, Meteor packages through Atmosphere would still make sense, wouldn’t it? If ES6+ modules via NPM, etc makes it’s way into Meteor with 1.3+, I guess Meteor packages would be too crippled by comparison unless they themselves could make use of ES6+ modules and specify dependencies from NPM, JSPM, other registries, repo’s, etc. But if that were possible, I’d say Meteor packages through Atmosphere definitely has it’s place. Both in terms of making Meteor work as a (very approachable) platform and not polluting NPM with Meteor-specific stuff.
This guy writes it incorrect on purpose, telling this whole post is stupid and Phoenix is bullshit even not trying it before. We gave him the points, where we think it is better than Meteor and where it helped us, but he still tells, that we are “undercover guys, selling it here”.
This is the topic, where we want to unite people, who have problems with Meteor and are searching, how they can be solved (with even using another language), where we can share our explorations and maybe some people will try Phoenix too.
If someone thinks Meteor is the only framework in the world and the other are garbage, please close this topic and never come back. We are here not to blame each other, but to find solutions to the problems, we all are facing.
Thanks, I’ve been on mobile all day and got Phoenix spelled incorrectly added to my dictionary and autocomplete while typing.
It feels like a bunch of opportunists are grilling Meteor and its community for the noise around Blaze right before the holidays when MDG is probably and hopefully enjoying time with their family. I check these boards from time to time to keep up with Meteor. Lo, this post is just stuck at the top of the forum for a few days with a bunch Phoenix zealots padding each other on the back and resorting to childish antics at even the hint of criticism or a balancing point of view.
@shcherbin
"I don’t have such simple apps"
“Meteor is (only good for) novices to jump in and start prototyping.”
@ryanswapp “you can make a silly web app into a mobile app with the cordova integration, but if you try to make anything useful you won’t get too far”
Tactless.
It’s no secret that Meteor is one of the top rated projects on GitHub and seeing this opportunistic swoon from the Phoenix advocates doesn’t say what it should “our framework stands on its own merits to solve a specific class of problems”. No it’s not a Meteor replacement and doesn’t do everything Meteor does but better.
Here is also the book from the video above to dive in, which in on 40% sale till 1 of Dec.
I also have a demo repository of webpack/react/react-router/phoenix/websockets with a roadmap. Currently, you can find, how you can setup your project, chunk-load the app with webpack on different routes and how to send data via channels.
Feel free to add topics you are interested in and want to see on trello.
And how’s the Phoenix job market? Wouldn’t want to end up on forums of other frameworks to rely on my affiliate kickbacks to get by.
I’ll look over the starter project later this week if I find the time between. Lots of hype here and lots of smack talking about Meteor devs building toy apps or whatever. Insulting people’s intelligence isn’t a good marketing tactic.
