I don’t want to speak for everyone, but I could not possibly disagree more with this premise. Personally, I’m in pursuit of the best development platform I can build and bring to the world, and sometimes that makes making hard decisions and tradeoffs, just like in any other engineering project. I’d also say that the business and engineering goals of the project are well-aligned - growing the developer community and keeping up to date with popular and well-supported technology from the wider community is a huge benefit to engineering. It’s very hard to do engineering inside a closed box, the best ideas come from an interchange of ideas and thoughts. To me this is like saying “we already wrote a bunch of science books saying the earth is at the center, and it basically works - why should we rewrite those books to allow for the sun being at the center?” and implying that the reason is to sell more books.
This is an absolutely fair point from someone (sashko) far more likely to be privy to the truth of the matter. That said, I’m not sure I want to be on board for a quixotic quest to achieve development nirvana in pursuit of a mythical “best development platform.”
Keeping up-to-date with the JS development community in near real time is certainly one approach Meteor can take. What I think the community was hoping for from Meteor, however, and at least what I was hoping for as a technology decision maker for my organization, is some sort of leadership that taps the breaks on technological churn in the JS/web-dev space. Leadership in this case would mean curating technologies constantly emerging and disappearing near the event horizon at the forefront of web development and driving their adoption by distilling the most promising technologies into a platform that can be easily developed (and planned) against by those with somewhat less tolerance than an “anything goes” approach.
If what I have described is not what Meteor intends to offer I’ll just have to live with that but I certainly feel that a lot of us were led to believe this was the Meteor value proposition to the community. From where I sit it looks less and less likely that Meteor will provide significant relief from the “Javascript Fatigue” (sorry for using the label du jour) a lot of the community is concerned about. This represents a missed opportunity IMHO.
Anyway, I definitely appreciate the willingness to engage on this issue. It’s a healthy sign that I’m still hopeful will ultimately result in positive final outcome for Meteor and its community.
This is getting a bit too confusing at this point. Soon after last year’s post, I switched to React to start a new project after all of the MDG recommendations that that was the best way forward. I still like Blaze better than React in terms of project building experience, but wanted to go with something that would be supported. At the end of the day, I really don’t care about which one is superior, because I haven’t seen any compelling case that one is that far ahead of the other.
With this post, is Blaze back as the recommended engine? Will it continue to be updated? Did I waste my time learning React?
I really just don’t know where to go at this point. As the year progresses, some view layers will be prioritized naturally by official and community packages. It is really impossible to continue to improve the Meteor platform while being view-layer agnostic. It would be really great to have a bit more of a clear scope as to what the future intentions are.
Yes, from my perspective this is the goal. It just happens that React/Angular2, GraphQL, and NPM are the “most promising technologies” you are referring to, according to the people at MDG, some production users of the platform, and some prominent community members like @arunoda, and in many cases in the wider industry. Consider how many technologies out there we didn’t jump at - gulp, webpack, flux/reflux/redux/rxjs, typescript, riot.js, bower, brunch, and countless others.
From my point of view we were holding the fort on stability until new users and production app developers were starting to leave because we weren’t integrating some key new technologies. I think anyone would agree, NPM is the place today to get JavaScript technology from the source.
Consider how many technologies out there we didn’t jump at - gulp, webpack, flux/reflux/redux/rxjs, typescript, riot.js, bower, brunch, and countless others.
This is true. But remember: Something as important as the view layer can’t be switched by a business on a whim though, so I hope you guys don’t flipflop again. Make a choice, stick with it, and us Meteor devs will be productive as all hell. There is nothing like Meteor out there, we are so empowered to build businesses with Meteor it’s a shame there’s only 24 hours in a day.
I made the jump to React based on your personal recommendation @sashko and my productivity is awesome now, and my code is cleaner for it. Just stick with it! 
For those that have switched to react or angular- this is ALL noise preventing you from going forward. If you have made the transition and like it, keep going with it. There will be meteor developers, like myself, contributing to the other ecosystems (angular and react). There are bugs in Blaze, which were not addressed in the post. So those that already decided to move towards the other view layers are in good hands.
There are bugs in React and Angular that are not being addressed. But it doesn’t matter, just use whatever you like and what is best to build your app. The only difference now is that people who choose Blaze can stop worrying that it won’t be supported anymore.
This announcement is a big win for people with large projects built in Blaze. I find it surprising, given the push towards NPM and away from Atmosphere.
React or Angular or Blaze are fairly useless without their community contributions. (You could use them, sure, but you’d never get to market quick enough without also complimenting community packages.) React-router, ui-router, and iron-router are classic examples of bread-and-butter contributions in each of these view technologies that begin to make them palatable for rapid development. Here I used routing as the concern, but other analogous view-layer concerns could be used as well (generating/validating forms, etc).
Blaze will always be dwarfed by React or Angular contributions due to limited use cases (e.g., exclusively with Meteor). Blaze does have great community contributions by excellent developers, but it will never fully complete in the greater JavaScript ecosystem. Blaze’s greater strength —full stack components— is arguably its greatest weakness. They tend to be painful to move away from, too. Like when I wanted to move from Blaze to React and I was using autoform. Full-stack components are not fun when you want to migrate off them. Speaking from my own development experiences, they’re kind of a big investment, and I learned that the hard way.
@gschmidt I’m gonna lay out a vision in a medium article for GraphQL and relay (influenced) stuff. There’s a lot you can get from us for free that you are paying employees for.
I would love to somehow engage in your internal conversation. Even other developers (@aadams @dinos) have mentioned they would love for MDG to respond to ideas I’ve put out. That said, this isn’t only about me–I’m just an example. I think in general, there is a lot of noise for sure and @sashko does his best to +1 ideas he supports. But he’s only one guy. You chiming in here is also a move in the right direction. But in general, most of the communication is 1-way communication.
What we need is simply: RESPONSE TO WELL THOUGHT-OUT IDEAS AND PUBLICATIONS BY YOUR COMMUNITY. How come @arunoda basically has to operate as a loan wolf monkey-patching you all the time. I rarely–if ever–see any comments/responses on his articles from MDG employees/partner. And that’s just using one guy as another example. So rather than more one-way communication–where in the past all we got was an occasional blog article–what we need is genuine listening to what we have to say.
There is great ideas coming from us that you’re missing and essentially paying people to find on their own. And with a lot more of us and some of us already passionately dedicated to certain areas (rather than just assigned to it), we may have a thing or two you haven’t thought of.
I don’t think you really listen to us at all. My perception is that you view most of us as a bunch of intermediate developers creating a lot of noise. Fine, but my recommendation is to sift through the noise and find the gems. Some of us might really have some insights about what’s best for the direction of Meteor. It’s a lot faster than waiting months for a few of your guys to research areas that community developers are already hyper aware about. At the very least, make sure as part of their research, they comment on such outside research. It shouldn’t just be limited to forum responses. In fact, the best stuff is likely coming out of Medium articles these days. Responses from core MDG developer precisely in that spot would–in my opinion–do the most to engage the community and flip our perception of MDG on it’s side.
For example, here’s several recent posts of mine you may be able to find such gems in:
-
I know–rather assume–@benjamn didn’t read this: Meteor 1.3 Wishlist for ES2015 Module Support + NPM Interface
-
I assume you didn’t read this (yet I’m pretty sure it was you who created Tracker):
Tracker 2.0: The Evolution of Tracker & Solutions to its Core Problems -
And here’s a general topic at the core of the Transparent Reactive Programming style Meteor used to be known for vs the more explicit yet boilerplate-laden approach React has the industry moving in: Tracker vs. Redux, Implicit vs. Explicit
I have an idea of how you’re working, and really like it, but I got some tweaks to it. Basically it seems the way you’re working is you’re sending out developers to do thorough foundation-first reports on various emerging technologies, basically as scouts. That’s smart. Your partner @dgreensp whose work I’ve been impressed by ever since he started appearing in Dev Shop videos wrote a great report on Webpack for example. That was extremely informative to me and basically did the trick of bringing me up to speed where most other material out there still left you putting pieces together on your own. So from what I understand you have @sashko and Justin Santa Barbara assigned to, what I’ll sum up as: ***“nextgen subscriptions”***. Right. Again, this is Relay and GraphQL inspired stuff, but with a reactive subscription-based focus like Meteor has always provided through LiveQuery. It’s my opinion that this is the absolute biggest area of evolution in the Javascript community right now. Your guys, me, etc aren’t the only ones doing lots of exploration in this area, but I’ll get back to that in just a second. …Basically, my recommendation is that you start Hackpads or similar from the start of these explorations, not after they are done; announce that you are starting them, and engage us from the beginning.
It’s always scary to address your constituents before you, yourself, have a voice. I get that. I’m not saying that @sashko shouldn’t do any preliminary research of his own. But basically do what you did with the Proposal for Blaze 2 Hackpad–just instead, actually apply what everyone came up with. That Hackpad really does seem to have been a success–the cream of the best ideas rose to the top. If Blaze 2 ended up being built, and the result was something that got a lot out of that Hackpad, it would have been a big win towards the aim of stronger community coordination.
I think currently with the Relay + GraphQL inspired stuff we have the best example of a “hackpad” sort of situation we can start now. And we should open up such a Hackpad. I’ll leave that up to you.
I’ll kick it off with my findings:
It’s my personal opinion that ClojureScript’s Om Next has absolutely nailed this (far and beyond what Relay currently supports) and you should use that as the basis for what Meteor is doing. In addition, unlike Relay and GraphQL, it isn’t just a specification/protocol. It’s concrete all the way down!
Here’s what is great about Om Next:
- it combines what Redux and Relay offers into one
- it allows you to configure multiple state atom’s as data sources (e.g. a client one for “UI state” [Redux] and a server one for “domain state” [GraphQL])
- it has subscriptions out the box! Minus RethinkDB, which is just the DB portion, no open source product (reads: Firebase is excluded) ever really offered full stack subscriptions–none that picked up steam at least (reads: Derby?? what is that?).
- it has full stack time traveling (not just client side time traveling like Redux)! This is thanks to the Datomic database, which keeps a record of every mutation ever mad, and which would be a challenge to replicate otherwise, but is definitely doable via snapshotting and the oplog for small development databases.
- it simplifies the boilerplate needed to get the Relay-inspired stuff up and running. To be sure, it’s a major benefit that they aren’t trying to support multiple databases like GraphQL, but even then, it simplifies a lot that Relay requires you to do.
- it uses Datomic, which has built-in support for subscriptions (for the most part) and is the closest thing to the database described in the famous Turning the Database Inside Out video. Om Next is “observables all the way down” now!
I think we should achieve that but using GraphQL and Relay so that you can take advantage of their ecosystems. From application developers’ perspectives, they would be dealing with a wrapper of GraphQL on the server and a wrapper of Relay on the container. But underneath MDG uses raw GraphQL and Relay to take advantage of efficiencies it provides. Specifically, on the server (GraphQL) it will allow you to use Rising Stack’s Mongoose and Graffiti and add additional DBs more easily and on the client I’m sure something will emerge that makes it a good decision to use Relay. But just to re-iterate, what application developers use is a condensed simplified opinionated version of such. I.e. a way smaller surface area. If you don’t provide such abstractions, there would be no value-add provided by Meteor, which would be a bad thing; there would be no reason to not just use NPM + raw React+Relay+GraphQL. So there needs to be a value add provided by Meteor in the form of a simplified abstraction. And, luckily, this isn’t just a solution to a problem that doesn’t exist, but is actually a problem needing solving–if we thought React required more boilerplate, Relay and GraphQL requires 2-3 orders of magnitude more boilerplate!
Here’s an example of how Om Next simplifies the Relay-inspired stuff (notice primarily the query function):
(defui Person
static om/Ident
(ident [this {:keys [name]}]
[:person/by-name name])
static om/IQuery
(query [this]
'[:name :points :age])
Object
(render [this]
;; ... bla bla ...
))
This is a complex topic and requires deep knowledge of GraphQL, Relay, React, Redux and what’s going on in our functional programming counterparts: Elm, Cycle, ClojureScript (Om Next and Re-Frame), etc. I think this will be a major win for us all to talk this one out together. I think we should all share our findings via various Medium articles and respond to each other there as well. I think this is the perfect opportunity for MDG to come out of its shell. And generally the perfect time for Meteor to come out of its shell.
My Final thought is: as the greater Javascript/NPM ecosystem acquires what Meteor has exclusively offered for years, we need to come up with new opinions. Meteor was opinionated in an area that is now more generally abstracted (or at least in the midst of completing its final stages of which). Meteor’s success relies on it being opinionated. Unfortunately (or fortunately, depending on how you look at it), we need a whole new round of opinions to offer a value proposition worth betting on instead of using “bare metal” NPM. It made sense that only MDG contributed to such opinions the first time around (since the community didn’t exist). Therefore, it’s the perfect time for not just MDG but the whole community to contribute to them. A hackpad would be the perfect place for us all to form them.
Not true. Blaze is built upon web themeing technology. Even if Blaze itself is a separate code set, the approach of direct replacement into HTML themes has been standard with websites way long before React saw the light of day. There are many themeing engines that use this approach. People are excited with React as it is made by Facebook. When that abates, it will be a framework like any other.
One of the challenges on this forum is that you have both fresh developers and veterans.
As I found out from the Blaze 2 hackpad, it’s not always the best ideas that rise to the top. If you’re not careful, you just hear from people who post the most comments and speak the loudest.
How can we design metrics for how we can get input from the right people and seek those people out, vs. just going by what happens to be posted the most on a specific document or forum?
I disagree (to a degree). What we are looking at is an increased signal to noise ratio vs the 500 post thread case in point (among, at this point, many related threads). Sure, you gotta do some weeding out of the best ideas still, but we have increased “signal” by a vast degree. I surely was able to spot what I deemed to be the best ideas all living in the Blaze 2 Proposal Hackpad. It wasn’t like some discoveries weren’t made there. We just need to find a way to reduce the noise even more.
In short, I agree that a “republic” can be better than a full “democracy” at this point. An algorithmically-controlled Republic, if you will, is what we need.
There have been several platforms over the years that are strategically designed from the bottom up to rise the ideas with the most votes to the top as well as contributors with the most support to the top. We should simply find the best such platform of today and use it. Whatever that is, is likely the best we can do unless we wanna build it ourselves.
On a side note: i’m not opposed to building such things ourselves–I personally think it’s bad for marketing that we are using–as I recall–an Ember-based forum that totes realtime as soon as you first signup, but isn’t built with Meteor! Something is very wrong if our forum is all about realtime features–Meteor’s core value proposition–yet isnt built with Meteor. It’s things like this which we gotta correct about our culture. Believe me, I get it’s hard to do everything in software, but this could be the perfect opportunity to correct that along with making community contribution a first class priority. This might be the rare case where building our own custom solution is the perfect opportunity. I think MDG should have some internally-built applications that many of its developers are familiar with. If built with the community, would be a great exercise to say the least. Are there any “consumer applications” that MDG has built that we use? U know, like a blogging platform, forum platform, social network, etc. One criticism that I’ve heard in relation to this before is: MDG doesn’t have much actual experience building apps. If we do this right, we can correct that while hitting many other birds with the same stone.
Back to the main point of finding a system that most effectively rises the cream to the top…I don’t see this as an unsolveable problem. I’m glad you’re asking this question. It seems that this is the first time this is genuinely being asked (since you wouldn’t be asking a question that has ready-made answers for had it been previously deeply thought through). Rather, it’s finally being asked! So let’s just find that platform, and use it. Ben Kaufman, founder of Quirky (a crowd-sourced platform for physical products) started out with a product called Kluster like 5-7 years ago for crowd sourcing ideas more generally within companies. Off the top of my head, nothing new is coming to me, but there has to be like 100 such similar offerings now.
I believe you (MDG) should be able to handpick 5-10 smartest people from the community - I guess we all know more or less who they are - and prioritize their comments/opinions above others. Maybe even invite those to a more or less closed conversation (but readable by all) if hackpad or whatever forum does not support such prioritizing.
Not saying that you should not listen to others, but as you say, there probably will be vast amounts of noise and it will be time consuming to filter it out.
So from what I got…
On one hand we have MDG
who will put their effort into Galaxy in order to make some cash and when they have time for their open source projects they might make some update to meteor meanwhile the official view layer will be Blaze which they sell as a good solution for beginners and legacy packages that are hanging on Atmosphere.
On another hand we have KADIRA (mantra)
Embracing React and offering smart solution to keep building applications on top of Meteor making use of NPM and js. trends, but not only we get a React but we also get to choose which database to use… and wait they also maintain the new official router flow-router along many packages that contributed to make what meteor became.
What sadden me the most is that even thought KADIRA as a company has it’s own reason of developing Meteor, it’s sad to see they do deliver what MDG fails to deliver…
I would even say that MDG need a new leader for 2016 and that an active guy like @arunoda might be our guy.
If not… I don’t get why KADIRA doesn’t just fork Meteor because if they don’t… in the end… I don’t think KADIRA will get the a piece of the cake they deserve 
Seeing how poorly the view layer issue has been addressed i’m starting to feel more confused and think that Meteor future is dark… because view layer was only one issue out of many…,
If there is nobody to make smart decision and not changing every month then I am worried about the future…
We won’t need to worry about changing the view layer again… but more like changing framework
One solution could be to get the good MDG members into KADIRA and let’s make Meteor reborn again …
I love Meteor and what you guys made but seems like time has come to change a few things ,
Happy new year ~
ps: @faceyspacey, @mordrax, I feel you guys ~
Does this mean we’ll see some React components written for user accounts just as we have for Blaze? Is this something MDG will work on or is the community expected to do it? What about stuff like redux, flux, relay and graphql?
All in all, it’s a tough situation. When Meteor came out and for years after, there was nothing that could compete. The real truth is that it’s still true to this day, but that day is soon coming to an end. Nothing in plain Javascript currently offers full stack reactivity. Firebase is closed source and far from a complete solution. RethinkDB is just the database and requires you to manually hook it up to a webserver as @mattkrick has done with Meatier . GraphQL and Relay is slated to have subscriptions, but doesn’t yet. When that day comes, MDG will have to cook something MAJOR up if it wants to stay competitive. Otherwise, there’s no way people like myself can recommend Meteor anymore for top tier apps–not when NPM allows you to customize even more, which top tier professional apps will always eventually need.
It’s a tough one. It’s why ClojureScript is looking more and more like the answer to me. If everything is going functional, I rather just program in a functional language to begin with. If it’s geared towards being full stack from the start in combination with Clojure on the server (which is the same language, plus a few lesser-used features), perfect. If it’s reactive by default and even has a database built for such subscription-based usage, I mean I don’t even know what to say about that–that’s a dangerous combination. If it’s combining the best of React, Redux, Relay, GraphQL already, from the ground up with no legacy APIs to support, hmm. The only downside is I have to learn a new language and new programming paradigm? And for many that’s probably not even a downside, not when it’s upping your programming skills to such a degree. I personally have enjoyed it, and it’s been exactly what I need at this point in my career where I haven’t focused on a new language in some years. So you do the Math–Meteor absolutely positively must come up with something groundbreaking/world-changing again if it wants to not get lost in the sea of options that will be competitive by this time next year.
I love Meteor, and owe a lot to Meteor, which is why I’ve taken the time to voice a lot of this. I’d like to see Meteor have what appears to be the never-ending lifespan that something like Linux has. Meteor may have the opportunity to be the operating system of the “connected client.” If it want’s to achieve that level of permanence, something else will need to be dreamt up. But right now, Meteor is risked being dethroned over night. I guess what I’m saying is: Meteor can’t even win if it does a perfect job at copy-catting the latest and greatest (and whether they can do that is far from a known at this point in time); it needs to come up with something as groundbreaking as Relay + GraphQL. The question really is: is Meteor a “one trick pony” [full stack reactivity] like Google has always been criticized for search, or does MDG have something new and equally (if not more so) magnificent to bestow on the world of web development?? And most importantly, what is that, what would really make Meteor the OS of the connected client?
ps. this is the first time I, myself, have thought of these questions framed this way–but what quickly came to mind is: being the brain of all possible clients (browsers, phones, desktop apps). So, a way to really feel like you’re at the center of a codebase serving all potential clients. Really nailing that in a super consistent idiomatic way would be big. It really looks like–once Relay/GraphQL has support for subscriptions–everything else is nailed. I’m less of a fanatic about MySQL support than many, but I guess if it could show it offers support for at least 2 databases, then Meteor will really come off as a sort of operating system that lets you plugin in whatever software you want into it. It seems the GraphQL abstraction layer will go a long way to promoting the development of support for other databases. It will push a lot of common problems into code that can be shared between multiple DBs, and in doing so pave the way for plugging in more DBs. Nail integration of Reactive Native and Electron on the top of the stack all from a single folder in your file system that you can run commands on all utilizing shared code, then you have a recipe for success.
I guess that’s nothing new, and likely the realization MDG had when they brought in Cordova support. But it still needs something to feel more like an “operating system.” A command-line only operating system like Linux maybe worked 25 years ago, but in 2016 we need a GUI. One you can access whenever you are working on your app in the browser, similar to Dr Mongo and @msavin 's Meteor Toys. You open up the panel and you can see big buttons for each device you support, you can click each and you can examine static stats for each codebase. I say “static” because there would be plugins for things like @arunoda’s Kadira to display aggregate/statistical runtime stats within the platform. That way MDG wouldn’t be responsible for building all of it.
Anyway, one can pontificate forever. Clearly MDG is moving in this direction and execution just takes a while. I guess I’m just saying, marketing is an important aspect, even if all the sub-pieces of the puzzle aren’t ready yet. And to achieve that use a web-based GUI to give the feel of a real operating system, not just run time stats in galaxy of your server, or what kadira does, but something you can use in development before you even launch your app that gives the feeling that all the clients you support are orbiting around your Meteor server, that you’re achieving the closest thing possible to the “holy grail” of write-once-run-everywhere. I think at this point in time–especially thanks to React Native–we’ve come to understand that write-once-run-everywhere is pie in the sky. I’m very ok with what React Native has come up with–based on lots of experience at this point of the custom needs that apps of different screen size and capabilities really do have, I wouldn’t even want write-once-run-everywhere. It makes a lot of sense to put deep fine grained control across-platforms of code-reusability in the developers’ hands.
So that’s the sort of stuff this GUI could help you with–do things like product “coverage” stats of how much common shared code you have, and let you drill down into the files. Perhaps, wire up different github REPOs for different clients–that way they dont have to all live in one repo, but your meteor app can conveniently see them all is one (that perhaps is the killer feature here!). I don’t want to make an Electron app by copy/pasting generated client code into the of an Electron app. That’s an obvious one, and obviously Electron is far down any sort of Roadmap.
You get the idea: Meteor needs to really supplant itself somewhere to have the sort of permanence Linux has. The whole competition with NPM needs to 100% be eliminated asap. We have to be 100% NPM compatible (for reasons discussed elsewhere). Once we do that, we’re in a scary point in time–because then if that’s truly done right, Meteor is only a build tool, and one which will be replicated using Webpack or other (so you can run the same codebase without calling meteor from the command line). So for when that time comes that Meteor has essentially given all its value back to the NPM community, it needs to have a new Killer App, and that’s a panel of sorts as just described. Then from there, the business concept is that it segways nicely into the even better paid Galaxy panel, which takes production/runtime stats into consideration. But both should feel like a consistent experience. The latter a natural evolution of the development experience. From a marketing standpoint, that will give javascript developers something very solid to look at and latch on to and say “THIS IS METEOR. THIS IS WHAT METEOR PROVIDES ME. IT DOESNT REMOVE FROM THE GREATER NPM ECOSYSTEM. IT LETS ME MANAGE ALL [or at least %80] THE TOOLS MODERN APPLICATION DEVELOPMENT REQUIRE.”
I personally feel your post is a bit nasty. MDG has done a great job developing Meteor and getting it out there. Remember that there are many competing frameworks (e.g. derbyjs) and yet this is the one that succeeded.
Why @arunoda added his own pieces into the cake makes sense. Meteor is open source and we each look for a way to improve things (MDG could have avoided this by accepting more PR’s into their repos, but, no one is perfect – they are working on becoming more open).
No big open source project can succeed without some sort of commercial custodian (e.g. Cordova, Linux, Drupal) there has to be money down the line. It’s an ecosystem. As far as Kadira is concerned, they exploited a missing offering as MDG was focused on the platform. All this will change as you alluded to 
FOLKS! Stop complaining! Things are back on track now. You are not happy? Write code to improve things or use some other platform.
I am in Academia, and it sounds odd, but the most acknowledged method to prevent the loudest voice, or the person with the most prestigious CV or CS degree, is called a delphi study. Controlled feedback is particularly used to not value the loudest voice. I’d agree that a hackpad, without a moderator, can end in chaos.
Close to real-time delphi: http://www.codigital.com/
If you need a handful more alternatives: http://www.capterra.com/idea-management-software/
Edit
So I’d consider “how to collaborate in tech” a solved problem. It is a question of willingness, since there is orientation all around us. Just ask the guys from linux, to apache to node.
I think this is a great decision! Even if there’s currently no more information about the future development of Blaze. I for one love Blaze and its simplicity, but see that React needs to be let in too.
Looking forward to Meteor’s 2016! I’d love for Server Side Rendering in Blaze to happen
You realize the vast majority of developers are only just leaving jQuery DOM manipulation to something like Backbone/Angular/Ember/React. By merely being on these forums, it puts us above most developers. And some people are yammering on about moving over to GraphQL (lol), ClojureScript (lol), Elm?! Really? I can’t see a team picking any of these technologies to build something solid because it’s entirely too new.
Suggesting something like Clojurescript is downright crazy.
I wish the people who build product would post here more often than the tinkerers. We would see a more even sided discussion. Everyone is criticizing MDG about not going HAM on newer tech that is just not proven yet.