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.
So try koajs, but rails?? for me it was mess a bit and I could never build complex thing in rails and you lose chance of nice simple JS full stack solution.
Few words of react:
React is definitely way to go, I’d not choose some old fashioned 2way data binding mess when you can have
nice clean react+flux = perfect control over changing data = state. and it’s native to andorid & iOS
For me react + meteor is really a nobrainer
So it’s been about a week since I wrote my initial post, and I have decided to give Meteor another proper shot - keeping in mind it’s limitations and just plowing through the barriers. So far it feels like it’s been a great choice, I have a proof of concept application just about ready, and honestly if it weren’t for Meteor this two day endeavor would have become a three week march.
I’m currently wrangling with the last bit: Using the camera on iOS and Android - but so far haven’t had much luck, but we’ll see how that pans out.
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.
