I am also frustrated with all this Meteor platform volatility nonsense.
Blaze meets a need. It’s simple, easy to learn, stable, and an effective tool. You can build re-usable components. For many apps it’s all you need. Why Meteor would so quickly abandon this technology baffles me. Yes I use the word “quickly” here - I know it’s been like a whole year since 1.0 was released (I think it was Oct 28, 2014). But to me it feels like the paint on this shiny framework just dried and now we’re redecorating. WTF?
But of course it’s really not about Blaze or React or Angular or whatever the next thing is… is it?
It’s about users who use your application. You know - the one you’ve built or are currently building. And the entire developer community - a number of which like me are all about using a great tool to build great stuff and NOT about adopting new technology for technology’s sake.
If the tools you’re using to build this experience are sitting on a sea of shifting technological sand - everyone loses.
Instead, I’ll argue MDG’s focus should be on responsibly evolving this awesome framework in a way that doesn’t leave developers in the dust.
A few facts (according to me) to ponder:
Meteor will never please everyone
Having an opinionated framework that is the best tool available for certain type of jobs is a good thing
Quickly adopting new technologies at the expense of obsoleting apps already built on the platform is a bad thing
Meteor got a few things right (reactivity, data on the wire etc) where other frameworks missed the mark - that’s why we’re all here.
I’d like to see more leading and less following going on around here.
On the other hand, generalizing is a very bad thing in a long run. As much as “crowd mentality” - “opinion” of the group doesn’t necessarily mean they are right, right?
We are witnessing large groups of people being mislead each day, while outvoting smart individuals within (and outside) of the group (political insinuations are intentional …
Disclaimer: I’m not an official member of the core team! Just a heavily invested community member. And while Meteor Cookbook is probably the largest resource of its kind, it’s not an officially sanctioned resource.
That being said, what people probably don’t know is that the initial integration of a Meteor in Webstorm was lifted from the Cookbook. Same templates, spelling typos, etc. I spent a year piecing together the outline of what eventually went into Webstorm. And I got frustrated with Webstorm being written with Java, and hopped over to Atom where I could hack on the editor itself. So, that’s why the recommendation for Atom.
So, now here’s the question… Sublime and Webstorm are the most popular editors because they have the most features out-of-the-box; but neither are written in Javascript and neither will reach the same level of isomorphic integration that Atom can get. Is Webstorm the best isomorphic editor? Or merely the most popularly known editor?
Already, we’re using a Chrome isomorphism between Client, Editor, and Testing Environment, and it’s a beautiful thing. And Webstorm can’t offer that. So, by some standards of comparison, Webstorm isn’t even a consideration.
But not everybody is looking for an isomorphic editing experience. So it boils down to using the right tools for the job. What are people trying to achieve? Are they truly following the Seven Principles? Can Sublime and Webstorm users say they’re following the principle of Pure Javascript if their editors aren’t built in Javascript? Is this a question worth asking? Does it border on being ideological?
I guess what I’m trying to say is that Meteor has some architecture principles, and recommendations like Atom over Webstorm are in accordance with those principles. Even if they’re not the most popular solutions. By that wisdom-of-the-crowds reasoning, gasoline cars are the better solution because they’re more popular, even if electric or hybrid cars are available.
Nice to see you again Abigail! Points well taken. The wisdom of the crowds is certainly not a panacea, but I think it works for all of us some of the time, such as when looking at book reviews and products ratings, when looking at aggregate opinions of restaurants and hotels. It’s why solutions on StackOverflow have ratings and why Atmosphere shows number of downloads and stars on Github for it’s packages – so that we can maybe save time finding a package which is good enough by leveraging the opinions of others, rather than evaluating them all for ourselves.
But yes, of course, it’s a not a flawless heuristic. Books reviews can be bought. Once great restaurants lose their edge. And better solutions on StackOverflow can be be overshadowed by popular but unwise approaches.
My point was just that the opposite approach is not without risk as well.
“A foolish faith in authority is the worst enemy of truth.”
― Albert Einstein
Regarding Webstorm vs Atom, first thank you so much for your work which helped get Meteor integration in Webstorm. I haven’t used Atom in a long time, but when I did I felt like it didn’t offer a fraction of the features we had in Webstorm. I think the potential of what Atom could become is great. But if my team and I are more productive with Webstorm, I don’t care if it’s written in Java, Fortran or b****fuck But that’s just because we are a commercial business. if I was an academic researcher or tool builder I might think Atom was a more interesting line of development.
Anyway, I didn’t mean to single you out or anything. It was just an example that popped into my head. Another example would be file structure. It’s popular for people to organize files in their views according to the style popularized by Meteor example apps. I think our way is better (which I picked up from a @mquandalle project).
A core value of the Meteor guide so far has been using the opinions and common practices built up in the Meteor community to drive most or all of the major decisions. The idea is that instead of looking around at all of the options yourself, you can trust us to do it for you, and know that everyone else is looking at the same set of decisions. If you don’t trust the recommendations, you can always pick something else, but I think there’s huge value in having a “default” for every decision.
@awatson1978, for me, the biggest difference in WebStorm is debugging, if wasn’t for that, i would use Atom probably.
Node.js is working in a Chrome DevTools integration for debug but today there is already an alternative to node-inspector called iron-node.
If it had a smoother integration with Meteor, certainly Atom would be a better alternative. The author tried this integration but stopped in the final path:
And Meteor still locked in old Node.js version, won’t get soon any modern alternative.
Well, it’s not bad, do the job… but node-inspector is just a html page simulating DevTools, it’s buggy, not much interactive, makes the debugging iteration slow and it seems the same but don’t have half the features of native Chrome DevTools.
Are you replying to my post? If so, then we must be talking about two different things.
I’m talking about $ meteor debug
Then going to the URL it provides. From there it’s just as the client side. No bugs, very interactive, iteration is fast, and has every feature that WebStorm has and more (I know, I’ve used WebStorm).
Right, there’s nothing else we can use to debug on the server side in Chrome. Anyhow, I’ve never run into node-inspector bugs and it seems just a feature rich as client debugging to me. WebStorm is using node-inspector too. The only difference I can see is that the debugging happens inside the editor with WebStorm, and to me this hasn’t been much of a loss.
Ok, i don’t think it’s a bad debugger at all. But i came from other languages where you can get a good ride only experimenting the possibilities even without have to stop debugging and compile again, among other things that saves time. Node.js is yet maturing in this area, it can get much better, and throught a long day of not expected variables, every second in a wrong debug iteration makes some difference in the end.
Yep, especially true with how outdated node seems to be with meteor.
but it’s slowly losing it’s focus pandering to the hipster programmer and not the actual “9-to-5”.
but it’s not a front end framework
awh.
(built in router / built in models)
There probably shouldn’t be built on models or routers, Surprisingly, I have made an application which needed neither routes nor models. but an “officially supported” package that can be added would be great.
yes, that sounds quite useful. Microsoft has done the same thing with best practices for .NET. Just saw your interview about Meteor Guide . Looking forward to it and already learning things from reading the project discussions.
