For anyone learning Meteor: don’t look through the Telescope source code! You will feel a crushing sense of defeat as you examine it and have absolutely no idea what’s going on. Even if you know a bit of Meteor and have a built a few small things, looking through Telescope’s source will make you want to throw your computer out the window and take up a career as a farmer.
But on a semi-serious note: man, it can feel really overwhelming looking at this code, and (for me, anyway) it kind of makes Meteor feel a bit unachievable. For people new to Meteor, I’d recommend sticking with simpler tutorials and apps.
Actually, when I began Discover Meteor, went through 4 chapters, I moved to implement my own app. After 2 hours, I looked at the source of Telescope.
I felt like everything I have been doing is wrong! So I revised all of my code, changed every damn thing. Then my code started looking better, manageable. Then I went back to Telescope again, and felt the same way!
How would you describe that kind of implementation? By unachievable, in this case, do you mean it’s a situation where there’s a high learning-curve for proprietary patterns, as in more on the side of incomplete or non-intuitive organization? I would have imagined meteor in many ways to be pretty great for effective architecture.
It seems to me that beginner content is oriented too much towards absolute beginners. I’ve been programming for a long time now. So I would like to see content that is for beginning Meteor and not programming.
And after the beginner content, there’s no intermediate step that could help me build Meteor apps with the same (and better) level of sophistication. Telescope seemed like a huge step, 4 initial chapters of Discover Meteor seemed too less! (I don’t have credit card so haven’t been able to get the basic package either )
There’s another post about starting Meteorcasts. I’ve been subscribed to Laracasts for some months now, and I found the videos to be greatly helpful!
May be it’s just me who has not been able to find proper content, but well.
Hmm, good question. Something just freaks me out when I look at Telescope’s code. At least I opened it up in WebStorm where I’m able to cmd-click a name and it’ll jump to its declaration so I can quickly trace things. But there’s just a lot going on that looks really foreign to me compared to all the tutorials I’ve read.
I wondered if it was on purpose that the meteor API actually makes for a great design for those really simple little introductions at conferences, but every one I’ve seen has been nearly the same.
It seems meteor in general markets for beginners as a strategy, while aiming to lay the groundwork for a technically powerful environment. That makes sense, and I’m glad to see it, but I wonder how come we find such a gap in the content breakout at this point, assuming that’s the case.
I haven’t looked at it myself, so I was just trying to get a feel based on what you had said. Yeah, you and quark and I think many others would appreciate some more tutorials. I guess things are a little too new to concretely standardize in the best way just yet?
Edit:
With what I’ve learned here, I think as working parts are still moving around, we don’t have an intermediate-tier ready to be established, and that’s why getting beginners in the door is optimal for the time-being while I suppose high-tech proof-of-concepts work things out.
One issue with many Meteor tutorials out there is that they all generally cover the same stuff. We need something different, but I don’t know exactly what it should be.
People seem to be questioning their gut instinct a LOT here…
I may possibly be a total moron and a lousy developer, but the Telescope source code looks to me like 1) it’s a victim of committee post-design, aka "rip the guts out via lots of indirection for everything all too often"
2) it seems to do things in very non-meteor ways. State has been moved out of collections, session variables, etc, into hardcoded objects.
3) the meteor package system appears to have been hijacked to use as a telescope package system… for example, how shall I override lib/config/at_config.js ?
4) it appears that #2 is due to the fact that Telescope appeared before many Meteor things were standardized… It still uses handlebars (vs spacebars) inside in some places…
5) Meteor.startup blocks required wrapping template helpers, seriously?
Folks, Telescope may be a very useful and great app, but it’s not a boilerplate. It’s an anti-boilerplate. It’s the sort of thing we are running away from, by getting on board the Meteor train.
We need to make things a lot simpler…A lot of people just jump right in and start hacking the javascript but don’t look at what the platform itself is doing… Spend some time thinking more stupidly, like the developer who will have to maintain your code at 3am…
Less folders. Less indirection. Abstraction means making a simpler outside interface! HIDING functionality surfaces with a uniform niceness… No more ad-hoc API’s please!
If it really warrants de-coupling, then design it that way and make things obvious how they fit together…
I do not believe such complexity is warranted… Ok, flame away… I do apologize for being arrogant, rude, etc… I just cannot believe that this is the way to go…
I just seriously think the world could use a good dose of actually looking at the minimalism of the demo app, the file loading order, the canonical ways to achieve reactivity, security, state, etc…
I’m currently working on a project called Meteor Fresh that I hope to be a starting point for Meteor apps. It’s taking a more modular approach via a package-structure. We’re working on turning it into a “yo” generator soon, as well as finding a reliable way to test a package-based Meteor app. It might serve as a good learning project.
Even if you know a bit of Meteor and have a built a few small things, looking through Telescope’s source will make you want to throw your computer out the window and take up a career as a farmer.
)