Next steps on Blaze and the view layer

Good to see you here @mweststrate. I meet Mobservable today, I see the “word” on various post and google search´s but until now I didn’t know anything about. I migrating a App from Blaze/Tracker to React/???, Right now I don´t know what choose: TrackerReact, Redux, MeteorFlux … Mobservable?? … it took me time to learn Javascript, Meteor, MongoDB, Blaze and Tracker …
The magic behind Tracker is invaluable is a shame that his creator is not more involved @glasser.

@mweststrate a Mobservable/Meteor examples/article will be invaluables for incomers/newbies.

1 Like

I totally agree with you on the advantages of a well designed TRP model, especially for large applications with a lot of state views. I just wouldn’t oppose this model with the possibility of having a state tree ; being able to serialize all components state into one big data structure is very appealing. For instance, in development having to replay 3~4 clicks/actions to get back to the state of the component you are working on is very frustrating and time consuming.

Last time I encountered Mobservable I didn’t read its Gitbook documentation, but your comment here motivate me to just do so :slight_smile: Maybe you address this question of full state serialization in it?

1 Like

The way I read

https://github.com/rackt/redux/issues/1176#issuecomment-167015145

is also not that he talks about abandoning the state tree.

Hi @mquandalle,

Good question. The assumption that only trees are suitable for efficient state tracking using shared (immutable) data structures has dragged on too long :). As demonstrated here and explained here with a little effort the same can be achieved when using observable data structures with the same performance characteristics in both CPU and memory consumption.

Granted, you have to write a serialization function (which are usually trivial and can most probably be generalized). But on the other hand, when using immutable state trees you are also writing serialization functions, except it happens in the rest of your code instead of a treating it as a seperate concern in a separate derivation.

No definitely not, the point is just that to keep things performant in redux you have to use connectors or a library like reselect to get performance in decently sized apps. So in practice it isn’t as simple as the initial idea is (which I really like btw, it’s just that our CPU’s aren’t fast enough to do a naive full top down rendering)

Yea, we can get time traveling with TRP too.

I do agree 100% that TRP vs redux once we have our tracker problems fixed is better, more elegant, etc. that’s one conclusion I’m sure of. It’s basically all hype that redux is this fix-all. It will be replaced by relay once relay support client stores anyway.

I also agree Cycle.js’s use of observables everywhere can be awkward. However Elm seems to get everything just right.

Om’s implementation of react and relay-style features is also on point. I’ve been leaning more and more to clojurescript as I go. I’m picking it over Elm because it has a full stack masterplan in the final stages of unfolding much like Meteor via its database, Datomic, and via Relay style features which are in fact better than Relay. Om uses React but at least that gets u many more targets such as iOS and Android. It also has better ways to achieve Elm style signals constructs better than any other option besides Elm.

That said, I think TRP is absolutely perfect for intermediate developers and the best in the business for them. It’s unbeatable for this audience. Let’s fix tracker, and make it a first class option to use along side React, and onboard new Meteor developers in that direction. All the other options are way too complicated for the vast majority of developers. By promoting the Facebook react stack we basically are severely cutting short the number of possible developers that can access this stuff. To pain the picture of what I’m saying I’ll say this: I personally think having to import packages and variables is overload for even intermediate developers. That needs to be optional. Therefore setting up redux reducers, action creators, connecting higher order component stores, setting provider context etc, is way way too much for these developers. Relay too is way too much. The buck stops at React. Tracker and TRP is perfect for this skill level. Add a simplified relay subscription interface and call it a day. If u wanna use all that other stuff u can, but u shouldn’t have to and it shouldn’t be promoted on ur first introduction to Meteor.

@mweststrate any chance maybe you could help impart some of ur expertise from Mobservable on improving Tracker??

1 Like

I’ve highlighted the sentence above to draw attention a often overlooked point. If MDG’s aim is make Meteor widely accessible, why would it, seemingly, complicate the stack and take the risk of possibly alienating their existing users (the Meteor Development Community)?

Then I realized that we simply do not have a MDG mission statement. We do not truly understand what their strategic goals are. We don’t have the information necessary to truly understand why they’re making the choices they’ve made as of late.

This isn’t to say that because we are simply not privy to MDG’s objectives/goals and not inside the MDG circle of trust, we cannot make obvious conjecture on Meteors trajectory based on choices we can see and take issue with some obvious truths.


There are a few things we know for sure. We know them because they have been stated by Geoff Schmidt circa late 2015.

If we listen to the ‘A Look Forward’ video by Geoff Schmidt we know the following right now:

[All the following is paraphrased]

Meteor’s Mission:

  • To get JS where it needs to be it needs a integrated platform that everyone can use to make JS applications quickly and easily – without everyone having to reinvent the platform over and over again. This Motivation for Meteor.

  • MDG wants to provide a complete integrated end to end experience for building applications in JS.

  • MDG wants to address the fragmentation of JS.

  • MDG wants Meteor to be what Sun was for Java or what MS is for the CLR – a complete integrated platform that has everything you need in one box, already made to work together – thereby addressing said JS fragmentation.

  • MDG thinks there’s no where to run from Meteor, because If we are not going to use Meteor what are we going to use? We are going to have to put together a ton of pieces and we are going to have to maintain that.

  • The goal has always been to build an end to end platform that gives you everything you need in one box.

Forward Strategy:

  • MDG wants to broaden what they offer (in terms of opinions, structure, package recommendations, aka: integration paths) across the platform.

  • Position Meteor for the “Enterprise” in the same way as MS positions .NET.

  • MDG also wants to advance the tech they integrate with. This means from time to time replacing existing tech within the Meteor stack with the latest and greatest. React and Angular replacing Blaze for example. The stated rational for this is “if you get Meteor you get the best of JS”.

  • MDG is parting ways with the past by shifting focus from, as MDG states, a weekend developer or novice developer, to a tight focus on “professional web developers”. What does this mean? People that come into a office and build applications on Meteor. That’s MDGs new focus. The enterprise professional developer. From MDGs perspective, Meteor is already the best for the weekend developer or for the novice developer.


[All the following is conjecture]

The screenshot above is taken from the said video by Schmidt. As you can see, the free, faux-open-sourced non-profit infrastructure on the left, feeds the closed for-profit infrastructure on the right.

There has been a shift in MDG’s strategy as many can tell, yet the rational for this shift in focus is not discussed in the video. But I think we can safely make conjecture from the data gathered so far.

Rational:
In order to grow the right side, MDG needs to grow the left side. What better way to do this than to adopt the most popular tech of the day I say? And what customers will have the most resources? Well, the Enterprise of course.


Further, I think it cannot be helped that MDG’s new focus will be to the detriment of the existing (and future I might add) Meteor community:

The fallout:
When MDG decides to replace rather than organically grow tech within the Meteor stack, now and in the future, everyone that has invested in the existing tech will suffer. This will include the Enterprise – even if/when they subscribe to the Developer Subscription.


Unintended consequences:
I believe, if/when MDG has sufficient, resource heavy powerful Enterprise customers using either/or Galaxy/Developer Subscription plans, the pace in which they replace tech will slow substantially. Just look at Microsoft for an example. And the cycle will start over again.

Accessibility:
Going back to @faceyspacey’s original quote, it’s worrying that Meteor could become less accessible with the move to replace core tech with Facebook stack tech.

I for one do not relish the thought of throwing away our Blaze productivity in favor of the more cumbersome React API that seems to bring questionable value on it’s own and additional baggage when coupled with the inevitable complementary FB tech.

I couldn’t disagree with this more. Every single other commonly used language - Python, Ruby, and more - have a non-optional module system. There are thousands upon thousands articles about how easy it is to use Python, I bet all of those people were able to figure out how to import stuff.

10 Likes

I agree 100% with sashko.

If you have you’re brand new to Programming, having magic variables appear is likely more confusing.

Intermediate developers should appreciate the self documentation of where this module is located and how many dependencies a module has. It takes 5 mins for intermediate devs to learn.

3 Likes

“professional” is not just someone who goes into an office, or charges a fee for his/her services. professional can also be about someone who needs reliability, predictability, scalability to architect, deliver, update and support applications and packages that people can depend on contrary to something that can meet its goals with different quality requirements.

instead of thinking in separate tracks of meteor, eg. the beginner/prototyper and the more advanced scalable production type, the best would be if the beginner/prototyper is built on top of a solid flexible and scalable design, where the magic is on top of a declarative system, so the top layer of magic can be removed when needed. then there is a path from beginner/prototype/quickie to scalable/performant should it be relevant.

I also agree with sashko and skinnygeek1010. coming from a past with freebsd (compat and ports) and perl modules, this is a step up indeed. for those that want it, it may be possible to make magic package on top of this that abstracts the defaults with something that autoimports, and autopublishes, and insecures etc. but with strict warnings :wink:

I was paraphrasing from what Schmidt said in his video, he described what he meant by “professional”. I’m afraid none of what you state above is falls within what he states his definition of “professional” is at that time. You are I can only go by what he says.

1 Like

thanks for clarifying.

@sashko, the quote, you quoted here:

“I personally think having to import packages and variables is overload for even intermediate developers. That needs to be optional.”,

seems to be attributed to me, but of course I never said this and didn’t ever say I agreed with it. It was @faceyspacey’s original quote.

I know this is a technical issue, but when I quote someone that quoted someone else, I manually embed the original quoter – it’s only fair and proper.

1 Like

I clearly state that I’m paraphrasing in the original post @casperandersen. I went through the entire video and tried to pull out the best I could his quotes and ideas so we can have something tangible to talk from. When I made conjecture, I state that much in the original quote too.

1 Like

You’re right, sorry - I fixed it now.

Yes, I am wondering the exact same thing now.

I usually go by what I want to do, sometime as a reaction to what others do, but very rarely what others say they’ll do or tell me to do :wink: I lived a few years in France, so I learned my lesson haha.

1 Like

If you’re talking about my quote above, what I should say is,

if we want to get as close as possible to the truth, we have build our ideas and make statements based on facts; the rest is pure conjecture.

In this situation the only facts we have come directly from the leadership at MDG. And the only direct communication from the leadership at MDG that’s recent is at the very top of this thread and in the video I originally sited.

Otherwise, I agree with you more often than not. :slight_smile:

1 Like

You disagree that it should be “optional”!? So you’re advocating for slowly weening the Meteor community off the current system completely? That’s an option.

First off just, so you know my stance: you’re not talking to someone that wants to personally use the old easy way. I have barely been coding in Meteor the last few months and haven’t had that luxury. However, I understand and respect the needs of new developers. I can still remember the days where any bit of extra verbositiy had the potential to derail me. In fact I’m also worried about the effect all the new ES6 and beyond features will have on new developers. Less is more, especially for new developers. I think the current system has been ideal for those developers, and if we can keep it as an option, we should.

Now that said, I think it’s a bit outrageous that what you wanna do is take away what we already have, when we can have both. That’s one of the things that bothers me by all the stuff happening in the React Stack–they promote non-optional low-level coding, almost denouncing any higher level abstraction. Who are you or anyone to say that I shouldn’t have the option? I’m not coming around and saying to you, you can’t have your way–in fact I’m saying the opposite: we should have both ways. That’s a very different proposition.

Now that said, I do get the importance of such decisions psychologically in terms of culture and whatnot. But still recognize, one party is saying lets have both, and the other is saying essentially “fuck you, my way or the highway.” Such decisions are important, and perhaps I could be sold on non-optional imports as well, for culture, etc. But I do think Meteor is going to be in a very convenient place if they can catch up with the NPM community on other fronts, while still seeming super appealing to new developers. Automatic imports is one very key avenue to pursue/achieve that.

Regarding non-optional imports, maybe that’s true at the language level, but when you work in Rails, most your classes start out like this:

class Person < ActiveRecord::Base

That doesn’t seem “non-optional” to me. It’s been many years since I even opened a Rails project, but I assume apps there launch via a similar mechanism to Meteor’s where they control the environment. The environment I remember being made for me was a simpler environment and I appreciated that. In addition to being something we’re already doing, it’s something I think JS developers need now more than ever. If you’ve read the various articles about 2016 predictions and 2015 recaps, basically the #1 problem has been too much choice and the #1 thing that will change/happen in 2016 is consolidation and simplification, i.e. what Meteor has always done well. Reference the "Javascript Fatigue" article:

I don’t think we should forget that as Meteor goes into the new year. Rather than letting go of this “feature” at the precise time it’s most needed, we should double down on it. I’ve myself been one of the advocates for taking on all the new stuff and looking more like NPM. But that said, we shouldn’t switch too far to the other side because of our coming to jesus. My assessment is that the smarter choice is somewhere in the middle. In other words, we shouldn’t drop the ball here and lose the opportunity we have to be the source that consolidates things and makes things easier for all these NPM/Javascript developers getting slaughtered by choice and compositional-only procedural code stuffed in all these NPM packages. Our timing would essentially be backwards. The year that just occurred is the year where complexity/choice in the javascript community exponentially grew. Now, choice/complexity is a problem more than ever that needs a solution.

A novel idea is: Meteor does a rebranding, a “reboot” of sorts, coming to the rescue to all these developers struggling with NPM style code–once we have gotten module support, react, etc, right of course (since we gotta provide the upgrade path to pro apps as well). MDG has always toted they have done barely any marketing. Well, it’s time they do. It’s time they take control of their perception. If you go to the Meteor homepage: https://www.meteor.com you will see they say basically nothing about the major benefit that you have way less boilerplate code; the only benefit noted (over and over again) is that it combines everything you need full stack. In the New Year, it’s my predictions that there’s a huge market opportunity for a full stack solution that wants to come out and say: “look, you have the option to code in a way simpler boilerplate-less way, similar to Rails.”

In addition what I’m saying is that clean pure class-as-the-only-thing-per-file approach is very conducive to beginners getting up and running. There’s basically no denying that. All the imports at the top of files is definitely a hindrance to new developers getting started. Javascript not doing the one class per file like Java or Ruby is definitely slowing down new developers. It just is. There’s way more readability when there is one type of thing you’re looking at, a Class. It’s a lot easier to reason about a bunch of files when you know to always expect a Class in it. Opening up different packages and looking at a new rendition of the module pattern in some spagetti code is already hard enough. Since we barely do classes, at least give new Meteor developers something to make their life easier–keep the imports out (unless they want t).

Now, I’m not saying down the line there isn’t tremendous benefits from the composition-only module-based approach promoted by NPM, nor the benefits from friggin using Haskel and going 100% side-effect free thanks to FP. But for new programmers (programmers in their first 1-3 years programming), my opinion is that there is no doubt that looking at class files like in Rails is many times easier than all this nonsense, imports included. It’s no wonder functional programming has taken so long to take off: it isn’t just a paradigm shift foreign to long-time OOP programmers, it’s fundamentally more complex; composing functions of functions, transducers, etc, is super challenging to grasp.

PS. what I proposed to @benjamn in that Meteor 1.3 thread is that if a file is imported or imports other files, it’s taken out of the auto-import scheme. That way you don’t need to stuff your auto-import files in one /import folder and even have to make a decision here. Once you start using ES6 modules in relation to a given file, it’s no longer automatically required, and when and if it is imported, it not longer has the usual global variables in scope, i.e. it operates normally.

2 Likes

500 responses! a new record! :sunglasses:

2 Likes