Amazing. I've only dabbled with Meteor lightly, but this takes it to a whole new level. Telescope is so fast, you've done an exceptional job building this my hat goes off to you and thank you for open sourcing it so others like myself can learn how to build a Meteor app.
My only concern is what about search engine visibility? If I were to build an app like this with Meteor would Google see the page content?
Not sure how configurable this is, but would it be possible to have less ridiculous URLs? An idea might be to take the hash (it looks like you're using some sort of hash?) and then encode it base-36 like reddit, or even, (for a bit of individuality and human memorability) take a list of some number of words (preferably large) and encode it in that base where the digits are the words, e.g base-3 with 0 = telescope, 1 = dog, 2 = house, and so 3 = DogTelescope, 5 = (3+2) = DogHouse, 7 = (2*3+1) = HouseDog etc.
Oh wow, I did not know that. Well I'm sold, thanks for replying. Meteor looks to be a pretty promising way to build realtime applications, I see what all of the fuss is about now.
Curious about your "fast" comment. Tried to get in twice with the "Login with Twitter" option and things just spun and spun until they timed out. What are you commenting on? Speed of adding new articles or... ?
Sorry but is this meant to be marketing for Meteor or a legit project? Am I missing something or is there no test suite? This doesn't bode we'll if this is the example of how to write a Meteor app.
I think people have had some success rolling their own testing solutions for meteor projects, but it's all very ad-hoc at the moment, I guess this is the downside of working with a pre-1.0 framework.
Ok thanks for the information. A test suite should be part of the DNA of any framework in my opinion and the lack of prioritizarion shows the values of the meteor team don't really align with what I originally expected.
[meteor dev here] We actually have a great realtime test system that we use to test the framework itself. Whenever you save a file, your browser test console automatically updates to show which tests are passing and failing. It's great for TDD. We also have a script that runs a set of tests in the cloud, simultaneously on all supported browsers. I'm hoping we'll get that integrated directly into the test console eventually, so you get feedback on IE breakage in realtime. The current system's API (tinytest) is sort of janky, and before we bless something as the officially recommended testing system for 1.0 I'd like to see more experience with the framework and broader community input, which is why we've held off.
Where we are weakest is on tests that are driven by UI scripting. I was really impressed with the system we had for that at Asana and I'd like to do something similar in Meteor. But right now our priorities are opening up the package system and doing a round of server scalability work.
Don't underestimate the value of an early standardized test framework. This posting itself is a great opportunity to teach the community what a canononical Meteor application should look like and not having testing baked in makes the code a lot less readable.
I'd like to see what a fully decomposed meteor application is supposed to look like from an architecture perspective but every time I see an example it looks like this.
Testing frameworks force you to break things up resulting in a better overall design. This is what should be exposed to a nascent community if you don't want serious growing pains later on (look at the struggles the php world is having adopting testing and modular architectures)
Very cool. I am working on a music site right now in Meteor and really enjoy it! I will likely open source it after. Check it out thus far: http://tunes.meteor.com
I think there are lot's of improvements that could be made to sites like Reddit/HN. But thanks a lot for open sourcing it this will be very helpful to me in learning meteor!
edit: Just noticed you are planning on writing a book. Can't wait!
Also thought I would mention that I have recently gotten more into meteor and related technologies so am going to throw up some links others may find useful:
I also went about re writing the "peepcode tunes" app in meteor and then with meteor using the angularJS package. I know lots of people here like AngularJS so maybe you'll be interested. Here they are:
hah thanks!! I plan to do a lot more with it. I made http://tunesicles.com awhile ago. So am kind of rewriting it in Meteor because it's so awesome. It's so easy to add new things. But I will be adding playlist/logging in next. Oh and better searching (not just youtube).
I ~want~ to use Meteor on a large project, but they only are in Preview and in the FAQ states there will most likely be major API changes each [preview?] release, with no 1.0 release date in sight.
[meteor dev here] The latest plan for 1.0 is at http://roadmap.meteor.com/. It's too early to have a specific release date but it'll be well under a year from now.
Thanks for putting this together! I think more designers should be exploring the possibilities of these real-time frameworks :) Today, it just seems like something a lot of devs get excited about, but I think it's when designers get a hold of something that the REALLY cool stuff starts showing up.
P.S. I'm a subscriber to your newsletter -- great stuff! Keep it up.
I think Meteor is especially relevant for designers because it's pure Javascript. This makes it the perfect framework for designers and front-end engineers that want to build an app but don't know Ruby, Python, or PHP.
Thanks! Regarding the security aspect, the basic principle of data security with Meteor is to only give the client what it needs.
So while it's possible to send the whole database and let the client filter it, what you really want to do is only send the subset of data that a particular user should have access to.
As long as you do this, I don't see why Meteor would be any less secure than any other environment.
Put another way, Meteor does give you the means to shoot yourself in the foot, but that doesn't mean you should use them.
Although new apps come with the autopublish package turned on (which violates a lot of the security), any real application will have this package turned off.
Yes, I'm aware of the packages, `insecure` and `autopublish`. Once you remove these, you end up writing RPC methods (for the most part). This is a good thing.
Meteor makes writing distributed client code as simple as talking to a local database. It's a clean, simple, and secure approach that obviates the need to implement individual RPC endpoints, manually cache data on the client to avoid slow roundtrips to the server, and carefully orchestrate invalidation messages to every client as data changes.
So, meteor helps you write RPCs, imo. Just like most frameworks do.
I guess it depends on what you mean. If you mean data sent from the server -> client, then no, subscriptions[1] are a lot more powerful than simple RPC calls for data.
If you are referring to data sent from the client -> server, then yes, everything is an RPC call. But it's a bit disingenuous to say "basically meteor is just an RPC", when meteor does a lot of work to set up (and secure) the RPC calls you'll do most commonly: CRUD operations on the database.[2]
That is to say, calling `posts.insert({title: 'A new post'})` in your client side JS _does_ end up calling a method called `posts/insert`; but that method is wired up for you, including checking the allow/deny rules you've specified and tracking the user who is doing the inserting for you with no plumbing work required on your part.
I wouldn't say that's something most frameworks do.
I always prefer text as well. I can get the information quicker and if I'm looking for a particular piece of information I don't have to scrub through a whole screencast.
[meteor dev] I had a chance to meet Sacha and Tom a few weeks back. They're two of the nicest fellows I've worked with -- absolutely delighted to have them as leaders in the Meteor community.
Thanks! One of our goals with Telescope is helping more people learn Meteor, so it was important to keep things clear and simple. I'm glad you think we achieved that!
This is proof Meteor is not the future. Bloated JS heavy webpages that aren't RESTful or modular are not moving the web forward.
Aside from that, I don't see the utility of being able to see the stories change order, or comments come in. Especially once you have large numbers of comments and the stories reorder constantly.
I just don't see what is so interesting about Meteor - and I love node.js and JavaScript.
This is one of those often upvoted middlebrow dismissal comments that pg has said worsens the experience on HN. If you are going to dismiss something, at least provide more substance.
The arguments you stated have more to do with the product of choice than the framework itself. True, real-time changing of things like story order probably doesn't make much sense because it could become terribly confusing when lots of people are using something like telesc.pe. However HN likes to upvote HN clones to the front page because they make for great examples to explore a framework. It's certainly quite a bit more interesting and demonstrative of a frameworks pros and cons than the simple ToDo apps used to showcase most frameworks.
Please try your dismissal again, but with more thought this time.
I've been flipping off people talking about node.js for the last year, and seeing this made me take a step back and go, woa, maybe there is actually something here worth paying attention to.
If you are serious, be more specific in your criticism please. (not restful? large js pages? so what? It's easy to install, templated, pretty, fast. The code seems readable and hackable. That's all the things (except perhaps fast) that's been missing from the sites the node.js people have been showing me for the last year).
This site looks great to me... it doesn't have any tests (as mentioned somewhere else), but hey...
Look at it another way: what's the utility of not seeing the stories change in real time? What added benefit does pressing the refresh button give you?
If you're worried stories would change too fast, that's something that can be tweaked through the algorithm or the UI. In fact I spent a lot of time making sure the UI for new comments didn't disrupt the flow of the page.
Basically, what I'm saying is don't dismiss Telescope just because it doesn't work like what you're used to, and please keep an open mind :)
Since discovering Meteor, I haven't bothered using other frameworks anymore (apart from Jekyll for static sites). If it's dynamic in any way, I use Meteor. Once you're used to its paradigms (and quirks), putting something together that ties back- and front-end together is nearly effortless and an absolute joy. I've built several projects so far of various size and complexity, and unlike some of my older projects, jumping back in to add a feature a few months later is just so much easier. Less moving parts... More concise perhaps. Hard to put the experience in words.
So far I have two public apps built in Meteor:
http://my.groceries.io/
And my favorite for sending screengrabs to coworkers: http://my.sket.sh/
I have another coming soon that hooks Stripe and Zencoder up.
And next week I will be able to share the link to our company's Holiday special website, built with Meteor.
I can't recommend the framework enough, even in these early stages.
maybe its just me, but I'm failing to see whats so impressive about this. Couldn't this have been accomplished in any language, and after viewing source code .. I feel like could of done with a lot less code. While its fast, for a tech demo, I imagine for a lot of other framework/language combinations could be made to be this fast as well.
Well, the thing about Telescope that might not be immediately obvious is that it's realtime. Sit and watch the front page for a while and you'll see posts re-ordering as other people vote on them. Hang about in the comments page for a post and you'll see new comments queue up as people make them.
Meteor makes it easy to build such features; sure you could maybe make them happen in other more traditional frameworks, but I can assure you, it would be a _lot_ more code. We wanted to make an easy to understand app in meteor as an example to help people learn their way around the frame work.
We'll be writing more about these features and how meteor made them possible; watch this space!
I've been working with Telescope's code for just over a week, and Meteor since the beginning of the year, and I wanted to vow for what a pleasure it has been. The Meteor team is putting together something truly grand, and these guys in turn are doing a terrific job putting forth a great open app written in great Javascript, which is really a wonderful service to all those wanting to get into Meteor. I'll be the first in line to buy their book.
Congrats, I knew you'd make the front page, Sacha! And so good to know it's holding up, that changes my plans considerably, I'll plod on full steam on top of Telescope and Meteor.
For context, I forked this app for an MVP[1] showing Meteor's own roadmap, up for vote, in HN-clone format, which went live only a week ago[2].
That's actually part of the Meteor Auth package, it comes with a default design. I didn't bother styling it too much for now because Telescope will probably use its own Auth UI eventually.
Very cool. I spotted a little layout bug: Resize your browser to be skinny, you'll see that the "Sign Up/Sign In" text starts to overlap the header text and become unreadable.
I'm a fan of the telescopic mouseover effect, and the abundance of blue/purple. I was expecting it be an aesthetic clone, but you guys have done a nice job.
From the example sites, it looks like Telescope is extremely configurable. I haven't looked at the code yet, but is it considered production quality? I wouldn't mind a small bookmarking tool like Sidebar for Clojure/Clojurescript projects.
Thanks for posting this, awesome to see examples of polished Meteor projects!
This is awesome and really great to be able to read the source (like other have said). Why is it called an "open source" app? It doesn't seem to have any software license in the GitHub repo.
This means it's just a "source available" app but normal copyright applies. I think this can be a bit misleading but nonetheless congratulations!
Oh and by the way, the Telescope demo is hosted on a free Heroku instance. So far it seems to be holding up pretty good, with about 80 concurrent users.
Answering (1) for myself, I do everything Meteor in Coffeescript, and in fact I'm playing around with the idea of maintaining a Coffee-fork of Telescope, as I'm integrating it into my app.
Regarding CS: I don't think the meteor community looks at it particularly differently to the JS community in general; some people use it, some don't.
It's supported by the framework; I've used it on a few projects but now I'm moving away from it (I find the hassles of communicating with non-CS users about bugs etc outweigh the benefits it gives me). That's totally a personal opinion though.
I'll let Tom answer your first question, but regarding the backend database so far only Mongo is supported, although more database options are coming (see the Meteor roadmap here: https://trello.com/board/meteor-roadmap/508721606e02bb9d5700... under "Later").
My only concern is what about search engine visibility? If I were to build an app like this with Meteor would Google see the page content?