For those watching functional development consume our world (thanks to “The Facebook Stack”), and wondering whether even Tracker has a place in a unidirectional immutable Redux-dominated world, this article is for you:
3 Likes
here’s the various links from the article:
Sebastian Markbage (ReactEurope 2015): https://www.youtube.com/watch?v=Zemce4Y1Y-A
Sebastian Markbage (JSConf EU 2014 - Minimal API Surface Area): https://www.youtube.com/watch?v=4anAwXYqLG8
Mobservable (Tracker-like reactivity model already for React): https://mweststrate.github.io/mobservable/index.html
…Sebastian Markbage will give you deep insight into the mindset of Facebook and everything they are doing with “The Facebook Stack.” My summary is this: they plan to gradually make the entire javascript world take advantage of the best parts of functional programming, and Clojurescript + OM (being ahead of them) is their model. That’s the “read between the lines” summary at least. …But also they realize they can’t do it overnight, and until then they will mix and match with object oriented programming that everyone is familiar with. I think basically that’s their agenda.
Similarly, we must “mix and match” and include things like Tracker with React and Redux. I think we’ll get a lot more value here than people who have already jumped on the React bandwagon are expecting.
1 Like
I think Meteor is doing a pretty good job with the current direction they are taking.
Sure it would have been nice to see more things earlier, but come on, Facebook releases parts of their stack little by little. It’s complex and new technology for the web.
The work done on the meteor guide is the key.
I like how the guide is structured, the way they teach component architecture that makes sense and the rest. The problem in fact is that it is a little bit too late. I believe they relied on Discover Meteor to teach the community the best practices. But it was the total opposite. It was giving advices that relied too much on “magic” IMO.
The fact is also that at some point Meteor was the “new hot thing” in the JS world and now this period is over. People that want to be on the edge are disappointed but let them be. I want MDG to take their time and evaluate the JS world, and give me the best advices on how I want to achieve my projects, big or small. There is no ONE SOLUTION TO RULE THEM ALL anyway. No developer will ever tell you this.
There won’t be super fast hot module reload like for webpack in 1.3 ? It’s ok because if I really want it, I can use community packages. I just want the guide to lead me to the correct info in how to use it.
Let Facebook publish their stack and their awesome reactive graphQL/Relay stuff. Meteor will tell me how to use it if I want to.
The problem is the way React and the functional world has pioneered is far superior. Ur right, there is no one solution to rule them all, but there will be many rooted in the new functional approach. Anything pre-functional will suffer.
But that said, because of the response React got, Relay and GraphQL are coming to the table pre-validated. They are getting an immense amount of attention, and early on. And maybe rightfully so. From here a non-fragmented future all built on the facebook stack is looking like the new foundation for the web. Now I’m not saying a bunch of spin off options will not pop up, but they will be just that: spin offs. See, part of what facebook is doing so well, as I describe in depth in the article, is building at so a low a level as close to language standards as possible that it will allow a lot of things to be built on top of it. It’s not a proprietary library with a DSL like angular. As a result it will make for the perfect foundation for a lot of things to be built on top of. They are basically trying to replace the base development stack.
Combine all that with the fact it’s coming from Facebook and a massive team of devoted engineers, and there certainly is a risk that it becomes “the stack to rule them all.” The fact of the matter is they are doing a lot of things righter than ever before, fixing a lot of long standing problems with web development. Web development in 2015 hit its Renaissance period. I’d say in most part due to Babel. And Babel is the most dependable weapon at the core of Facebook’s strategy. A year ago you never saw the number of “import” statements you see now in code examples and tutorials.
So sure with things moving so fast and so many contributors, to some it might seem impossible to predict exactly what’s going to happen. But at the same time–and as we seen by the sheer number of “ship jumpers” to the React world–it’s clear that developers like to rally around the best perceived option. Winners do emerge: C, Linux, JavaScript, hacker news. We’d be remiss to not recognize that and try to align ourselves with the “winner takes all” option. That is, if meteor doesn’t have the stomach to built it themselves. At this stage of the game it’s too late–Facebook already laid out the roadmap. We’ll need better tooling, e.g. IDEs, and there are whole other categories of things that can be built, but I’m not sure that’s what MDG is about. At the framework level we need to best align what we already got with the “protocol” Facebook is making the new foundation for the web.
1 Like
I must agree (especially based on your article on Medium and Markbage’s talk). This is quite upsetting when you compare Facebooks view on the web compared to the way Meteor is put together…
That being said, do you think Meteor will “sink into the ocean” in terms of delivering “first class” web applications?
Not if I have anything to say about it. I’m working tirelessly to see if anything except the functional way is the best way. And my current conclusion is that we would already be all functional if its wasn’t for a reason. After all Lisp has been around for years. Functional programming–and I’m no expert, tho I’m working on it–likely lacks in the ability to abstract. That’s why functional programming hasn’t taken over until maybe now. Hence Facebook’s dogmatic stance on explicitness over abstractions–it’s a real challenge to build rock solid predictable abstractions. So for now they aren’t taking the high level abstraction route but rather are fortifying the foundation. That said, these same people are like Chris Granger who created Light Table who are enamored with Bret Victor’s prediction of some sorta future where a lot less code is needed–abstractions at some point will have to come back into play!
…Sebastian himself just got into functional programming as he got into React. Everyone is trying to piece the dots together to create the future web–even if they prematurely state it will be a certain way in all their enthusiasm.
My hunch is OOP will continue to shine in implicit abstractions that let novice developers do a lot with little verbosity. After all when ur a newb programmer, the biggest challenge for u is writing any code at all. That’s why the functional redux, GraphQL and relay thing won’t fly as the be all end all. I still remember when I was a newb programmer and barely could do anything outside of what Rails or whatever MVC framework I was using at the time strictly offered in its API and guides.
In short, the future–like always–looks like a combination of the best tools for the job. There’s a reason React wraps a functional approach in an object oriented class system. Think about it. Really think about it. It’s challenging to hook in things like life cycle hooks into pure functional programming, among likely many other such things. As an aside, I do see Facebook coming up with a solution for that: more usage of “higher order components/functions” to wrap components or plain functions at carefully placed locations within the flow, similar to what Redux advocates with connecting to stores. That seems to be the direction they are going in by attempting to kill mixins. …If they can eliminate classes altogether they will.
Another tangent: classes are flat and functional programming is supremely nested. Classes, like what you may remember from Rails, are supremely readable compared to a different module pattern in every NPM package and certainly more readable than endless functional nesting and chaining. Objects more closely mirror the human experience and will therefore always be easier for newer developers to grasp.
The question is: are these things “enough” to keep OOP in the picture in the face of the predictability benefits of functional programming??
My guess is that readability isn’t. Predictability trumps it. But there still may be some things where OOP remains a clear winner, namely its ability to abstract.
Even if that prediction is incorrect, everything takes time. I’d say we still have many long years where OOP is important. If we accept that software always has been and always will be a moving target, we can and should continue to invest in OOP. My prediction is for plenty of years to come the best approach will be a hybrid approach. Something basically like react where OOP style classes operates in harmonious coordination with functional flows, where each shine as the better tool for their assigned task.
For the time being things like life cycle hooks, mixins, inheritance, a consistent context represented in “this” will mean that objects are a main player. …I still remember the days learning how cool it was that “everything is an object.” Now it seems the cool mantra is “everything is and should be a function.”
Anyway, Meteor isn’t going anywhere. React is still trying to figure out where all this stuff stands. We just need to do the same. And I think combining multiple approaches in perfect order is the right thing to do. That’s as opposed to getting all obsessed with functional that you jump off the elm or clojurescript cliff, as tempting as that is.
Meteor’s biggest problem isn’t its lack of functional programming in my opinion, but it’s lack of a true class-based object oriented API. Every file you open should be a pure class just like in rails. Meteor should be the isomorphic realtime and reactive rails. Instead all our code is procedural slop. That’s the case with most of NPM. Inheritance was trade for composition at the expense of code readability.
I got so much to say about this topic, I could go on and on, but likely the best format is more formal posts. Basically the issues redux and react solve are mainly issues of the jquery era. The issues we meteor developers have been having pale in comparison to the “single source of truth” problem and it’s lacking that the jquery days had. We r pretty good. There are precise ways I’ll be outlining soon where we can achieve the same level of predictability as all the busy work react, redux and more than anything Relay will have you doing. We just haven’t been doing them and it goes beyond what the Meteor Guide begins to tackle, and some things are in fact Meteor-specific additions or packages we need. In short we can patch up our problems. Implicit abstractions can work with rock solid non-leaky abstractions. That was my point about the Bret Victor stuff. Google him if ur not familiar him. Basically the future is inevitably higher and higher abstractions, as I’m sure anyone from the entire history of software programming would agree. Sebastian is advocating that we give up abstractions. But he can’t possibly mean them all. He means trim the wrong ones and implement rock solid ones. The fact of the matter is Meteor is extremely rock solid. Surely the most rock solid realtime isomorphic framework, if not the only one that’s earned the right to wear that title! So we gotta do some soul searching and solve the same general overarching problems of predictability that the Facebook stack has pinpointed, but do so in our own way, without just blindly following the solution that fits their needs.
The problem with blaze and tracker in as succinct if a sentence as possible is simply this: sometimes you lose track of where the flow is originating. Just by stopping usage of the global session and using instance state instead u begin down that path. But that’s just the beginning. We gotta formalize more such ways that make flow predictable like redux and react does, BUT WITHOUT GIVING UP THE AUTOMATION THAT TRACKER PROVIDES. Whether that’s offering both simultaneously for u to choose for different parts of your app, or improving our form of automation–it should be both. The redux world is getting something extremely right. And so is relay. And so is react before it. But it’s the exhaustive guaranteed to work approach. It’s also the first genuine stab at this stuff in the JavaScript world. All we gotta do is simplify it without losing the characteristics of predictability it worked so hard to achieve. That’s perfect fodder for Meteor to capitalize on and be on top again. But we need to be bold and opinionated and deeply aware of the benefits of the verbose approach. Then we present our solution confidently and say: “you don’t have to write all that boilerplate and you don’t have to give up predictability.”
When TrackerRedux is done this will become a lot more than conjecture. That will be the tipping point–is my hope–in reviving meteor’s stance of implicit ease and being able to stand up to the react world without looking backwards and out of touch. React after all is basically blaming leaky abstractions. If jquery had all these issues with the single source of truth, even if their abstraction worked perfectly, it doesn’t mean it’s not leaky if ur having all the problems that react and even blaze clearly had to solve. What I’m getting at is: rock solid abstractions, if they are explicit, will put React, Redux et al to shame. That we think we r at the end of the line in the evolution of all this is rediculous. So let’s be the ones to make the next move. Facebook after all, according to Sebastian Markbage, is all about building us and everyone the new low level APIs we come to depend on. Let’s be the ones to take the ball they have passed us and dunk it. The key is Relay and GraphQL. That’s my prediction. Answer the following question and we win:
Whats the perfect abstraction on top of GraphQL and Relay that will be the next step everyone is clamoring for? What will the meteor-specific implementation of that look like?
If we (it doesn’t have to be MDG, hint hint) are bold enough to tackle this we will take the number 1 spot in the spotlight again.
Software is a moving target, but so much we have been waiting for is finally solved: native, browser inconsistencies, modern language features, JavaScript everywhere, consistent single source of truth-based view rendering, etc. I predict a slowdown in the base web technologies we use on a daily basis in the near future, and I predict this foundation allows us to go on to a new set of problems. I really do. I predict things are gonna become very standards based and predictable, at least for a longer period enjoyed than like ever. My hope is during that time we can finally focus on the things Bret Victor prophesied. But my point is–from a business standpoint–there will be a winner takes all dynamic for the final technologies we settle on, on this layer of the stack. Just like Linux won the open source OS wars. Just like there are clear winners in myriad toolset categories. But there will be like 4-8 core technologies that make up a sort of protocol we all end up relying on. GraphQL is shaping up to be that. If u look into relay–just analyze their site to the t–u will see they literally solved every single major problem in that arena! I means friggin rediculous. What Facebook has done here with the aforementioned technologies is so damn thorough. And based on all my research it’s precisely correct. If there ever could be a single “correct” answer it’s what they have done. BUT it’s the low level approach. The super thorough low level approach. Now we need abstractions. This may seem like a challenge for Meteor to swim in these waters since the aforementioned technologies aren’t done yet and it’s not clear how they will exactly pan out. Not to the average super busy developer at least. But this is Meteor or anyone’s opportunity–to connect these dots before anyone else can. In addition to it being an open ball game, another benefit is it means we can affect what these standards evolve into before they are locked in stone.
If I were @gschmidt I’d go directly to facebook’s offices and talk with them how Meteor can be the perfect and first partner/abstraction of all that they are building. Have a dialog with them with the topic being: “if ur building all this, how could we be number one organization that builds what you don’t wanna build that developers will likely crave for?” Just go in there and work along side Sebastian and make sure we wedge ourselves in there with what precisely what the whole ecosystem will need. If after all we can’t do that in one way or another, what will meteor have to offer in a year or 2?
That said it may not even come to that. All we gotta do is fully understand relay and GraphQL and combine that with our meteor knowledge, and envision what the best future is. I’m not done with my exploration here, but every day I’m getting closer to seeing what the optimum amalgamation of all this is. Likely someone like @arunoda already has. My hope for now is just to get active community developers like @arunoda and MDG core team members to see some insights about how tracker can fit nicely with react and redux. People are all amped on Redux and React right now. It seems people are too easily willing to give up Tracker and maybe even minimongo. If it’s the right decision, it’s the right decision, but mostly what we have is blind adoption. Well, it may not be blind, but I’m not seeing anyone really dissect things and putting the time into giving Tracker a fighting chance. And that’s understandable. This takes a lot of time, and u don’t even end up writing code. Consider it my job. Next week I’ll have a bunch more insights to share.
2 Likes
For a minute, I was gonna straight up post something like:
anyways, thanks for the deep insight - I’m dissecting some of your points right now, and will hopefully be able to get a better understanding of all ur points - after all I’m at the start of my road, only just getting my AP-degree in software development this january after only 2 years in programming.
I’ve spent the last 8 months almost exclusively with Meteor , and I hope I won’t have to dump my favorite toy out of the toolbox 
1 Like
@elgusto, but it seems at the moment MDG is taking Meteor in the direction of Facebook stack integration. In other words, they’re becoming a Facebook integration stack of sorts (along with webpack of course).
The problem with simple solutions is that they can be overly simple.
It’s good to provide quick start options, but they should be abstractions over solid, customizable foundations. Meteor of today isn’t. It looks great on your development machine, prototypes practically assemble themselves. Then you happily launch the product, turn production-level traffic on it and suddenly the CPU graphs are through the roof and interface is stuttering. And there is no easy, gradual way to alleviate these problems. In the situation I’m with an app all I can really do is rip out the whole data pipeline, from publications to minimongo, and replace it with something else. I can’t incrementally replace parts of the magic with hand-coded solutions optimized for particular use case.
This is why I’m now mostly writing ‘heavy’ React + Immutable.js code, picking Flux over Tracker, going to the ‘lower’ abstraction straight away. I take comfort in knowing the possibilities of optimization are there. I can budget my time in advance. It might take longer for the code to be ready, but there’s less of a chance I’ll have to re-write most of it couple months into production.
I hope the Meteor stack of tomorrow will provide this. But the Meteor of today is trying too hard to be approachable by everyone. In my opinion, it’s okay to require some level of skill before you can start banging out apps left and right.
4 Likes