Homegrown Everything


#1

In @joshowenscommunity interview of @debergalis (who’s hoodie we all want), there was a chat about the possibility of bringing in React to the ecosystem in an official MDG way.

I wanted to add to that. Yes, definitely add official support for other libraries (view layer or not, if the library is widely used in the web community), but at the same time please please please don’t stop having a homegrown solution for every high-level piece of the system.

For example, don’t let Blaze die in favor of React.

Meteor’s homegrown-everything (as far as high-level components are concerned, but obviously not things like jquery or underscore), via packages that are easily swappable with other 3rd party packages, is what defines Meteor.

The homegrown-everything should still be the default in an app created with meteor create, and the great documentation on meteor.com can explain how to swap homegrown packages with officially supported integration packages in order to use non-homegrown things like React.

The 2 cents of my humble opinion. :moneybag:


#2

I’m curious what the benefit of homegrown libraries is, in your opinion?


#3

Probably tighter integration, e.g. in the case of Blaze, re-rendering the minimum necessary in {{#each}}.

But I’ll let @joe develop the idea.


#4

That is actually at odds with a direct statement of core directives for the Meteor platform. Use open source components where they can be used. Also seen as ‘Embrace the Ecosystem’ here: http://docs.meteor.com/#/full/sevenprinciples.

I think the reason Blaze exists is because Backbone and Angular didn’t make sense in the long term and so they started writing Spark and adapted Handlebars. Blaze was written as an upgrade that would be more performant while also allowing integration with plugins from places like jQuery ecosystem.

We would have blaze is React existed 2 years ago? I think not…

I am all for homegrown where it makes sense, and that is the point that Matt was trying to make yesterday (I think) . Obviously experimentation and offerings from the community can/might/should do a better job in some cases and we should embrace that. Web development and OO programming certainly look way different than they did 10 or 15 years ago because of experimentation.

Just my $0.02


#5

Hey, Thanks for watching and bring up this topic, btw! Loved that part of the convo.

And yes, we all want that hoodie.


#6

I think quite the opposite.
Why is MDG trying to re-invent the wheel everytime ? Example : the package system.


#7

Because the package system offering right now is better than NPM imo. On top of that, NPM is already a cluttered mess, why add to it?


#8

Everything is perfect !


#9

Yep, and control of the design is in Meteor’s hands, not relying/waiting on 3rd parties for certain things that make a library work best in Meteor.

I think it’s also a psychological thing (I can get everything in one place, read the docs for everything in one place, use a single command line tool, have a single place to discuss everything, get to know a large community around it all, contribute to a single cause rather than going to multiple 3rd party projects, less fragmentation, etc). I think that’s just nice.

Homegrown features that compete with 3rd party libraries also promote healthy competition and create new ideas.


#10

I think that the main issue (and this affects much of the contentious issues in the Meteor community at the moment) is that there is a dissonance between peoples idea of Meteor and what Meteor is and what MDG are trying to achieve. It stems from

“Since the parts of the stack integrate seamlessly, if you don’t want to think about how it all works, you don’t have to” [1]

Meteor is seen a full stack solution, akin to Rails or Django, and as such it should do everything and not just that it should be opinionated, there should be one way and only one way to do something. Monolithic but easy to use even for a beginner. This view isn’t inherently bad and on the surface Meteor does appear to be such a solution, however it really isn’t; As can be seen by the line directly after the above quote.

“But if you want to dive in and learn how the parts work, you can do that too, because they are independent projects.” [1]

Meteor is a platform, it is a set of tools that solve a lot of the common issues that are needed in all modern web application. (data persistence, package management etc) but the whole point is that they are just tools, you can pick and choose as you like, for example if you just want the backend, grab a DDP client and use Angular or React. Or if you just want blaze, do it and populate minimongo with backbone (Though I will admit this is not supported well at the moment) It’s up to the developer to decide which features are appropriate and where to use them. And the fact is that these are hard decisions to make often with no clear answer only compromises.

MDG have gone to great lengths to ensure that its incredibly easy to create a package that does something new and more importantly share it with the community. Have you tired doing dependency management in other frameworks? so we have our ruby.lock and our bower_components and our npm_modules…

It is a chaotic time in the world of web development at the moment. The amount of churn is utterly ridiculous and it is foolish to expect MDG to fold in and officially support all new tech that pops up. Even if they are technologies that a log of people like or find useful. Let the community do it. Do we really think that Iron Router or Flow Router would exist if MDG supplied one? And yet each has their strengths and solves different problems for different people.

As has been mentioned already there is a psychological component at work here, due to the churn, that if you invest in a community tech rather than an official one it may be abandoned or become obsolete and you will have learned it for nothing.

The real issue is not with official support its having better documentation, (which was touched on in the interview) people see how easy it is to get started and then hit a brick wall when they can’t find the router or support for npm package x.x. People who stick with it quickly realise how to solve their issues by interacting with the community but I assume that many just give up or write it off as being immature instead of realising that many things are in fact missing by design. I think better guidance from MDG would help, but then again I don’t think there is an easy solution (though trying to officially support everything is clearly not)

Note there are 2 major exception to the above assertions. SQL support, while I personally believe it can be solved with community packages, there is so much stigma about it at the moment that it scares off people, its always the top critisism on hacker news and the like, and it will do so much to impove Meteors image that it is worth the unneeded effort. And the second if supporting new standards, like ES2015 and Web Components and now Web Assembly etc.

As always these are just the opinions of the author and should not be treated as anything else. :slight_smile:


#11

In my opinion there can’t be one thing for everything at all. If we speak about Meteor as a FSF (FullStackFramework) we speak about an completed integration of the server and client part to one coupled system, which is mainly based on ddp and the server and client side APIs for data flows in both directions.

Isn’t it enough? It makes sense to work on blaze. It’s good to start learning meteor concepts with blaze. But I think it would make more sense to decouple the templating system because now it’s so, that you have to use it by default. It’s like the insecure package before the accounts system ) But the accounts system is needed for the Data Infrastructure… It’s very important and every meteor project relies on it, on the server and the client. But Blaze is like jquery, it’s only a client side thing (for now).

It should be possible to choose the UI Framework you wanna use. There are a lot of good angular, react and what ever developers which would like to use meteor like firebase. Just by adding a file to their existing project and have all core meteor features there, like AsteroidJS is providing.

So I would like to see multiple standard-app-packages (for different UIs, targets etc.)
Like standard-ionic-package standard-embedded-package standard-react-package

My 2 Cents too )


#12

@debergalis said in the latest interview that Blaze will be decoupled from Meteor and support for React will be improved.


#13

Please excuse my jumping-in suddenly here… I’m partial to random opinion expression.

+1 for greater integration. Minimalism, and particularly contextually applicable essentiality are generally better for homegrown stuff, aka less need to throw everything in (including the kitchen sink), less need to fit every possible scenario.
Generally, you will notice that there’s an integration going on inside the homegrown eco-system, and layered constructs that really only make sense in the Meteor context, i.e. packages like emmerge:graviton, or the autoform eco-system, or the accounts package.
In many ways, “industry trending libraries” are detrimental to this: They take the focus off of “The Meteor Way” (The ultimate best practice when using Meteor, it seems) and they achieve things in different ways to mate with various traditional stacks, and this leads to non-homoiconicity and confusing code that cognitively jars with the rest of the code… just my 3 cents…


#14

Great! I can only agree with him.


#15

It’s just the The Cathedral and the Bazaar discussion all over again. Meteor gained momentum pre-0.6.5 with providing a Cathedral like integration. But then people began second-guessing the architecture with their preferred libraries, and there have been heavy shifts towards a Bazaar architecture with 0.6.5 and 0.9.0.

I often miss 0.5 days, and the clarity of architecture and process back then. I’ve sometimes thought about going back, and forking from there, since there’s been a slow watering-down of the architecture since 0.6.5. For those people who came to Meteor looking for a Cathedral approach and a coherent integration, many of the changes as things have moved towards the Bazaar philosophy has felt like being thrown under the bus.

A good example is D3. Meteor shipped with the leading data-visualization library prior to 1.0, and worked as a coherent data-science platform. For folks who are concerned with Mongo and D3, and don’t care what’s in-between, Meteor was the best thing since sliced bread. But Node/JavaScript developers who weren’t database/data science folks, they started second-guessing the architecture and wanting customizability. And since they spoke loudest, MDG responded. And since the data-science are a niche group, D3 got removed, and Meteor isn’t particularly differentiated from a MEAN stack at this point. As far as data-science goes, anyhow.

Those of us who built custom homegrown libraries around D3 integration with Meteor are in a bit of a lurch, and Meteor 1.0 was a fairly big step backwards for us.

The one silver-lining in all this is the publish-release command, and the ability to publish tracks (they’re essentially Meteor distros). I’m loosely working with a couple of dozen people - collecting requirements, building tools, assembling packages - and we’re looking at publishing a custom distro that will get D3 back in, and have a ton of custom homegrown libraries, and offer more of the Cathedral approach again.


#16

I think the “bundle everything attitude is wrong”, yes it is easy to start but then you have to mantain all the 3rd party software and it slow down the rest of the development… why Meteor still ship old the version of X ? Why can’t I use this cool react datepicker?

To me the layers of a SPA are UX/UI, Components and Platform,
recently I gave a talk about Material UI, React and Meteor and clearly the “Components” part should be outside the Meteor Platform. I mean, a custom DatePicker component should be installable indipendently if someone use Meteor or not, and Meteor (as platform) should focus more on the its real unique features:

  • client/server data synchronization pub/sub DDP
  • livequery database support

So my answer is: non-homegrown libraries for the component part and embrace the ES6 way for the rest (which already is happening… promises, babel, …)


#17

An important response from Matt regarding the difference between a package being in core vs being community driven was the presence or lack of official documentation. He also added that a package is a package all the same, whether or not it is released officially by MDG.

I am buying into that idea, but also believe that there should be some middle ground in terms of:

  • MDG can hire people, or pay the authors, to document popular packages and perhaps even include/linkto such documentation @ docs.meteor.com
  • MDG can hire people, or pay the authors, to fix lingering bugs or implement high demand feature requests for those popular packages
  • MDG can semi-officially endorse some packages, perhaps via blog posts that promote them.

These would restore the perception we once had with Meteor that it is a full-stack, heavily integrated platform. Choice is good, but it is a double-edged sword that we should keep balanced with pre-vetted choices that suggest some direction.


#18

I think there are two different ways to do integrated solutions. One way is to completely isolate yourself from the rest of the world and focus on the best possible experience within the platform (see MS .NET, Angular JS 1.x, Ruby on Rails). Another way is to use open standards where it makes sense but ditch them when they are either not ready or not good enough (see Apple Safari).
The first way works great in the short term and when you are starting up BUT due to the isolation it becomes increasingly harder to adopt practices we define as an industry. .NET went through this phase by locking everyone to the same platform and significantly limiting possible adoption. Ruby on Rails is going through this phase now with “avoid javascript” attitude.
I hope that MDG chooses less isolated approach and uses ecosystem to it’s advantage so that if we fast forward 2 years from now, we won’t be blaming meteor for not allowing us to use React/Web Components/Whatever tech we adopt as an industry in the future.


#19

I think this is a wonderful idea. I have wasted a LOT of time evaluating all the different “boilerplates” starter kits and cookbooks, trying to discover all the bits and pieces that together form a “generally accepted best practice” implementation of Meteor. As it stands right now, I don’t feel I have any clarity at all about how to start a serious project where I will not paint myself into a corner for choosing an defunct or dwindling package.