It really is, MDG Meteor, Google Angular written in Microsoft Typescript and backed by Facebook’s Redux. Could never of imagined that five years ago.
Edit: And of course not to forget Oracle and Mozilla’s JavaScript!
2 Likes
If I had to name one thing about Meteor that has always been a pain in the ass for me, I’d say it’s that bloody awful Atmosphere.
I’m not sure if MDG guys are taking it into consideration, but for a casual candidate for a Meteor developer, Atmosphere is one of the first real Meteor webapps they ever see and usually the first they actually use. And the experience of using it is terrible.
It’s just soooo sloooow, both with access to data and with its shiny UI. And it leaves an impression of “what? Will my real life Meteor projects be so shitty too?”
What Meteor is missing is a complete rewrite of Atmosphere or redirecting people to Fastosphere if Atmosphere can’t be rewritten.
But Fastosphere may be gone too, with *.meteor.com going down soon.
6 Likes
You know, I don’t really use atmosphere much as I generally know what packages I need. I’ve found it to be a clunky experience so I just don’t bother, but until you said this, I never put thought into why I just don’t bother. You nailed it exactly.
2 Likes
In Meteor 1.3 npm packages will work out of the box. From there it’s only a few steps to having Meteor packages live on npm as well, so eventually there will be no more need for Atmosphere.
3 Likes
Except for build tools. Build plugins will probably always need a package to support them!
2 Likes
I want to hear a beep when meteor compiler finds an error and, therefore, doesn’t reload my page. As it is now I wait for a page refresh, sometimes it’s coming sometimes I wait too long to understand that I have to tab to the console window to check what error there is. Isn’t it a low hanging fruit for improving dev experience?
8 Likes
I am missing built-in support for:
- i18n that is reliable and also working on mobile devices (obviously, MDG is operating in the US only
) - SCSS
- DB schemas plus a model layer tightly linked to it
- Routing with SSR + fine-grained component loading on demand (like in Webpack)
1 Like
Never thought of it, but it would be such a great thing to have!
1 Like
There are plenty of great community packages for these. Core doesn’t have to support every possible configuration. In fact, what they’re trying to do is get less and coffeescript out of core.
Two different issues here
The first is solved by flow router, and again, it doesn’t need to be core, the entire eco system is defined as meteor.
The second would be awesome!
You should make a request for that on github. If they approve it and are willing to accept a pull request, I will look into adding this.
1 Like
Cool. If they want to accept a PR for this I’ll totally tackle it
1 Like
Any chance you can get something Apple in there? And IBM? I’m suddenly very curious if someone can come up with an application from every huge name in computing! (Include any I missed too)
Of course, I’m mostly joking…
I’m pretty sure you can write an Apple iPhone app with it.
Doh I didn’t even think about that one!
Visual IDE 
E.g. where you just add Template component and can create events (onCreated, onRendered, onDestroyed) just by double-click. Something from Visual Studio and Delphi world but really convenient. Though it is probably huge amount of work to make it work both ways (code <=> ide).
3 Likes
This is something Geoff talked about during his ‘bad idea file’ on Transmission, as in… it would be really cool to do, but would be a time-sink from a business perspective, and is still years away.
I’m not so sure. Personally, I think we may be less than a year or so away from an initial release. We have many of the pieces in place with the Atom editor already. And since Atom is already built on Chrome, the heavy lifting of getting the rendering engines aligned is already done.
The next step is to create a style sheet GUI sidebar for Atom, much like the Visual Studio ‘Properties’ pane. Once that package is written, we’ll have the pattern for GUI creation of components, and Events/Controllers tab for JS will follow. Last part will need some drag-and-drop functionality for the HTML.
The biggest technical caveats is that Atom is written in CoffeeScript. So, my prediction is that the first Visual IDE released into the community is going to be based on Atom, using a Coffescript component system. And what view layer supports Coffescript the best? Blaze. And who is working on CoffeeScript components? Mitar. (As I understand)
That’s how I see a Visual IDE playing out.
1 Like
Didn’t Atom drop Coffee lately? (which pains me, one less counter-example against Coffee-haters)
Did it? I’m not sure. If they did, it’s probably a rolling-migration.
Just checked - they didn’t drop Coffee. They unofficially said that they think of it 3-4 months ago and since then, nothing happened.
Manuel:viewmodel is Coffee too. 
2 Likes
Is it? Yeah, so ViewModel & BlazeComponents, then… they’ve been adopting the language and patterns used in Atom. Another missing piece would be an Atom DDP package; but I think that might exist already.