ZeSchool App -- Digital Classroom with Meteor / Blaze

Folks, we wanted to share with you the launch of our Digital Classroom application using Meteor. Already used by thousands of students internationally even before it goes out of Beta. Feedback from schools, admins and teachers is that it is leaps and bounds better than the next Learning Management System / Digital Classroom. It would not have been possible had it not been for Meteor.

Here is the ChromeBook version if you are interested in taking it for a spin (email me for user credentials if interested) https://chrome.google.com/webstore/detail/zeschool/dnkgfibmbiedenohnljjgideijmadkpk – here is the Web App version (https://zeschool.zegenie.com) – checkout the Wizards if you want to see a live demo / tutorial.

Short Story
We have a (VERY) solid PHP-based back-end, and were using Adobe AIR as our front end. Target devices are ChromeBooks, iOS, Android, PC, Mac. Adobe AIR became cumbersome and heavy to program in. Every new UI update took forever.

We used Meteor + MongoDB + Blaze + Semantic UI. Loading time is super fast (even with Cordova), code is very clean. We used the observer approach in our development (i.e. everything is an Event) and things work really well, including adding new features on the fly.

The total JS to download client-side is 2MB’s.

What we love
We are not embarking on React anytime soon, so we loved the fact that we can create our own components (e.g. Modals, Steps, Lists, Cards) in HTML / Blaze and re-use them throughout our App. This means:

  1. Faster time to market
  2. Faster fixes
  3. Faster feature(s) addition

Specifically, Adobe AIR was in a previous life using XML for its view layer, and enterprise loved this. Blaze / Spacebars / Handlebars are all in the same spirit.

Since this is not a compiled / linked app (i.e. Native or with compiled language) we are not necessarily keen on adding ‘imports’ everywhere. Pedantic vs. practical. We chose names wisely, so don’t expect collisions. Most of our objects are static, e.g.:

List = new function() {
    var self = this;
    self.initialize = function() { 

And then we can simply call List.initialize();

We do not subscribe to collections in templates. It is done in the respective classes that need them. Each class that has a collection is responsible for managing it, and sharing with the rest of the App what data it needs.

AtmosphereJS has also been great, makes it easy to add new Meteor-specific features (actually, it going down is a concern for us).

We love real-time reactivity! A teacher makes a change, everyone sees it live.

Performance on mobile is really great.

Custom Development
Aside from JS, we did some custom native Cordova development, really minor and very specific.

We developed our own State / Model. It simply dispatches events when things change. And it does it with deep diff-ing. This makes it very easy to react throughout the app to any changes. We have a couple of those states in use within the App at any given time (user, content, role).

We host ourselves on Digital Ocean. We would jump in a heartbeat onto Galaxy, but the challenge is that we are DB-heavy, so need Mongo to be nearby.

Next Steps
We are close to the end of our features list. What we are working on is some UI improvements, deeper integration with applications on School premises. Pushing mobile apps onto respective mobile stores.

I really think Blaze needs Incremental UI / Virtual DOM. I don’t see anything else wrong with it now (HTML is HTML). Maybe some cleanups of syntax, but nothing that is disturbing development.

We are very grateful for @aldeed’s SimpleScheme, autoForms and @fabien4 for the Semantic UI version.
We are extremely grateful for Semantic UI – leaps and bounds more dev-friendly than Bootstrap and Foundation.

The original design of Meteor really shone for us. As we played with deeper functionalities, we saw how well designed and built Meteor is. While I am sympathetic with MDG opening more doors for a wider adoption, I truly think Meteor is great, and under advertised.

Anyway, wanted to share the news (specifically that our use of Blaze has made a HUGE difference in productivity and ROI – we are very pragmatic organization, things have to work and have to work well.).


Another update over here :slight_smile:

[I got some messages that people were interested in our path, so I thought I would update on what we have been doing and our experiences as it could help many on this forum]

Users and Localization
Yay! Deployed to tens of thousands of users already, US, France (rest of continent to follow) and Middle East – in partnership with leading hardware makers. Which raises the issue of interface languages. We added French in under two days to a reasonably complex app thanks to tap-i18n. Next is Spanish.

Mobile Apps
We did it! Wasn’t easy, but we got Android and iOS apps pushed into the app stores. I have to say we were super impressed with the integration of Cordova. There are always kinks, but it’s so much faster and easier than playing with Cordova yourself. We used Crosswalk for Android and (for technical reasons) had to stick to UIWebview for iOS (vs. WKWebview).

A major challenge was learning to use XCode (on iOS, you have to compile the package generated by Meteor, on Android, you get APK’s out of the box). And you do need devices handy for Android as the simulator (well, to put it mildly) sucks big time!

This cannot be under-estimated. Thanks to the ability of watching / affect the console and the sources from the mobile app on your desktop, we were able to debug issues very quickly. We noticed that Safari iOS doesn’t behave 100% as Chrome and had to make some minor adjustments to our CSS and sometimes to event handlers. We would have never caught this if we couldn’t add breakpoints into the JS code live and step through it. On iOS, you can even add breakpoints in XCode in your plugins (on Android, you can’t do that, so have to keep watching the logs – adb logcat).

Push Notification
I wholeheartedly recommend @raix’s raix:push, as it works really well and in under a day, you have notifications and badges in your Apps!

What about React-Native vs Cordova
Our App needs Webviews, so using Cordova is by far the fasted path. [Also,we use Blaze as we like HTML-based templates more than JSX]. What is nice about the Cordova approach is that your code is 99.99% portable on mobile (aside from some potential kinks in how Safari iOS which are easy to debug, but you may not experience them). It seems if you take the React route, you do have to re-code parts of the interface into React-Native, but not for us, real re-use :slight_smile:

We talk in our previous post about a PHP back-end … that’s gone. It’s all Meteor now! We even generate PDF’s on the server, upload files to S3, generate thumbnails of images on the fly (with Node package Sharp).

We ditched …
No more @aldeed’s autoforms – package no longer maintained anyway, might as well code what you need yourself. Semantic-UI has built-in form validation which is very powerful. But was great to start so we can focus on functionality.

Next Steps

  1. As our user base grows, we need to start planning for failure of horizontal scaling with Mongo oplog, we have some ideas
  2. Apollo?
  3. Migration to VueJS or using VueJS wrapper?

Thanks for sharing your success story with Meteor. Please create a medium.com blog, so people outside meteor forums can read about what is possible with Meteor!!

If your app grows very large, and you need linked data, give this a try:

Incrementally adoptable + merges directly with your schema and database. Give it a try, it may be useful.

1 Like


I was a little bit confused about your third next step. Thinking about moving out of blaze? I’m in a bit of rush right now but I would love to discuss some implementations with you, as I’m CTO on a EduTech Startup on Brazil, currently serving 200k students. We are also using blaze.

BTW, Congrats!

1 Like

Hi @moretti,

Sure, would love a conversation. Congrats on your success. We are planning for the long term to either use the Blaze wrapper or migrate to VueJS. I don’t think it makes sense for this community to support a view layer.

Congrats again on an amazing looking site. I’m jealous of that client payload size, haha!

Also, not sure how much you’re willing to share, but I’d be interested in seeing some of your patterns for integrating Semantic’s validation into a Blaze-based app – what I came up with is working, but the amount of boilerplate to get me to a point where I can do things like tag an input with a data- attribute to init validation seems a bit crazy.

I’m on the same stack – Blaze, Cordova, Semantic – so it’s good to see such a polished product! =)

1 Like

Hi @vigorwebsolutions, thanks for the kind message. Sure, would love to share code. Are you ok if I create a gist or something. If I don’t have to clean up or document I can do it quickly.

Of course, that would be awesome!

Actually, it’s not that big. All our graphics (except bg) are SVG and semantic uses css for everything. We created simple Blaze templates for our UI (e.g. popups, modals, etc.) and simply reuse.

Yeah, I’m currently working through the blaze-components stuff, and although it will be a bit painful to refactor, I can already see the loc disappearing.

Also, 2mb is really great, I think!

I don’t use Blaze-Components package, I made my own.

Here is the HTML:

Here is the JS:

We use it as such
{{> Form header=myHeader description=myDescription fields=myFields footer=myFooter}}

Where each one of these variables may be a Reactive Var if you want a reactive form. Other, a static one.

1 Like

And oh yeah … we support Semantic UI check boxes too :slight_smile:

Cool, thanks for the gist, will give it a read through tonight!

And forgot to mention we use Tap-i18, hence the {{_ “string”}} for internationalization …

1 Like