"Is Meteor" / "Are the MDG" <insert negative connotation here>

[sam]

There are many of these threads popping up these days, so I’d like to weigh-in on what I think the overall problem, and also a solution.

Problem: Cheese Keeps Moving

In my opinion, quite a few of these these threads boil down to “Who moved my cheese?”. If you have never heard or read this book, here’s a video that explains the idea. In a nutshell, the cheese that makes everyone happy (for different reasons) keeps moving. Sniff & Scurry quickly adapt, while Hem & Haw resist the change.

At a time when the JavaScript world is going through a [Cambrian explosion]
(https://en.wikipedia.org/wiki/Cambrian_explosion), the cheese moving idea is more applicable than ever! So how do you survive in the JS-Cambrian explosion? By adapting and evolving.

Here are couple of quotes from Marc Benioff (CEO of Salesforce) that allude to the same point:

the only constant in the technology industry is change.

and

You must always be able to predict what’s next and then have the flexibility to evolve.

Solution: Focus on Agility

If you, your company and your code are going to survive the change, then you, your company and your code need to be adaptable so that you can evolve.

Writing adaptable code is hard, regardless of the framework you use. It’s easy to hack away and make stuff work, but it’s harder to read a ton of information, apply it, and become a better developer. That stuff takes investing time and mental energy.

To me, a major aspect of creating adaptable (maintainable) code, is creating a great separation of concerns. For example, If you separate your domain from your view properly, it will be a lot easier to transition from one technology to another. However if you write a ton of logic in your views, well then you’re screwed - and not just if the view layer technology you’re using changes / is deprecated.

Another big factor is surviving change is automated testing. If you have good automated testing which also respects the separation of concerns, you can refactor your entire view layer knowing it still works.

The above is applicable to more than just the view layer, it is applicable to software development in general. So rather than target frustration at Meteor and the MDG…

[goatic]

my lectors always keep telling me:

Software is a moving target

btw, they’re primarily teaching .NET

[arunoda]

And software is evolving and always there are places for improvements.

[khamoud]

Another big factor is surviving change is automated testing. If you have good automated testing which also respects the separation of concerns, you can refactor your entire view layer knowing it still works.

Which is why it would be nice to have a constant solid testing framework built in to meteor. My favorite thing about Golang is that it had testing built in from the beginning and it’s easy to use.

go test -v

That aside I agree with what you’re saying.

[mbrookes]

There are many of these threads popping up these days

No kidding - they practically need their own category!

[sam]

I also wish that was built in from day one. It had been possible to do, but was never “solid”, and we tried!

1.3 looks promising for testing, a welcome new addition.

[khamoud]

Yeah! I didn’t mean to suggest that Velocity or the work you’ve done for testing in the meteor ecosystem wasn’t good. I just think testing is one of the things that we shouldn’t have to rely on the community for.

I agree though. I think 1.3 is looking really good.

[peterm]

This is my concern about Meteor-- and no, this isn’t a negative comment, but constructive criticism. Geoff has said that Meteor’s greatest strength is full-stack components. I disagree, with the fundamental software engineering principle you’ve mentioned: separation of concerns. Full-stack components are an anti-pattern. When you have to gut them, it’s painful. They erode code reusability and flexibility in times of great change. Now of course, you don’t get separation of concerns for free. By their very nature, they introduce some overhead. It’s a small price to pay when you need to adapt new technologies, and retire old ones. And the only thing we can be certain of, is change.

[ffxsam]

Is Meteor a secret plan to DESTROY THE WORLD?!

Are the MDG really THE ILLUMINATI?!

(sorry, couldn’t resist)

[sam]

Full-stack components are an anti-pattern.

I’m not sure those are exclusive. You can still write a full-stack component with good separation of concerns. You can have view components that only take care of view concerns, like rendering and calling a service/method with some values from the component. Then have a service/method that does something on the client and server with latency compensation. That’s a full-stack component that works.

Meteor does it’s job of providing the infrastructure to do all the DDP transport, latency compensation etc, and the full-stack component would have it’s own design.

Did I miss something?

[rgoomar]

You can make it so you have some separation of concerns. You can setup two separate packages, one that is for the client and the other for the server. Both of which should not rely on the other explicitly. So, the client can have a component that subscribes to certain publications from the server. As long as any package exposes those publications on the server, it should work.

So, you can have:

package:component-client (client-side only)
package:component-server (server-side only)
package:component-full (adds both client and server packages - wrapper package)

And if the component on the client is looking for a todos publication to subscribe to, you can really have any package or set of code in your Meteor app that exposes a todos publication with an array of objects to the client.

It allows for a greater level of SoC rather than just having a single package with code for both sides that way if you change the client and connect to a different Meteor server, it can work by simply removing the server package.

I hope that makes sense, I’m pretty exhausted right now and may have typos and/or errors in my logic.

[sergiotapia]

Full-stack components are an anti-pattern.

If this dogma were true, absolutely nobody would be using Rails and last I checked Rails is popular as all hell because of it’s tight cohesiveness.

[peterm]

What is a full stack component? To me, it’s a single package that knows how to persist itself into long-term storage, knows how to paint itself in the user interface, etc. It calls all the shots and knows no separation. In terms of Meteor, such a ‘full stack component’ could theoretically use Mongo for its data storage and Blaze for it’s front-end. A great example of a full stack component like this would be houston. By using houston in your meteor project, you have no way to configure the database your storing to or the technology used in the presentation layer. There are consequences to being that opinionated. It can introduce a lot of inefficiency. For example, if you’re not using Blaze and add Houston, that’s now getting added to your client-side payload now, even being served to users who may have no need to access the houston functionality.

@rgoomar What you’re describing is well designed modules, not a full stack component. This is how we should be releasing packages into the Meteor ecosystem. Collectively, the packages form end-to-end functionality, but aren’t dependent upon one another. I think we are saying the same thing, but in different terms. Suppose package:component-client and package:component-server were a single, tightly couple packaged. That, in my opinion, is a full-stack component. All I’m saying is that’s what we need to avoid.

@sergiotapia: Full-stack components are unarguably a weak design decision. While Rails is a full stack solution, it doesn’t embody the concept of a ‘full stack component’. Rails is full of separations of concerns. For example, Rails uses Object-Relational Mapping so you can use MySQL or Postgres, etc. Through the ActiveRecord API, you have no idea what database is used under the hood when performing operations on records.

I think I’m rehashing a lot of what @sam said in his original post and that we all pretty much agree here, unless I am missing something.

[sam]

I think I’m rehashing a lot of what @sam said in his original post and that we all pretty much agree here, unless I am missing something.

We certainly agree that separation of concerns is good and needed for long term codebase maintainability.

I think where our opinions differ is around full-stack components being an anti-pattern. I agree that they can be written badly, but they could also be written very well. Accounts Templates is a good example of that in my opinion, and it solves a big problem for me - authentication.

But hey, at least we agree on something

[sacha]

What is a full stack component? To me, it’s a single package that knows how to persist itself into long-term storage, knows how to paint itself in the user interface, etc.

I agree with @gschmidt, this is one of Meteor’s key features. If you don’t want this, I’m not sure using Meteor makes that much sense anymore. Obviously making full-stack components more modular and maintainable is always better, but let’s not throw out the full-stack baby with the bathwater!

Related: this means that imo Meteor should be a somewhat monolithic, opinionated stack (i.e. something like Mantra), precisely to enable the existence of full-stack components. You can’t really ask someone to develop an Autoform-like package for three different front-end frameworks…

[vonwao]

Maybe testing is fundamentally not that helpful. Testing is one of those ideas, like MVC, that everyone loves to talk about but nobody knows how to implement well.

Static code analysis, good error handling, etc. seem so much more helpful, to whatever extent they are implemented.

[sam]

Maybe testing is fundamentally not that helpful. Testing is one of those ideas, like MVC, that everyone loves to talk about but nobody knows how to implement well.

Testing is not really an idea, it’s a practice. There are many ideas behind the practice. Just like Yoga, you start with 101 and you build up your knowledge. I wouldn’t say nobody knows how to implement it well (see the 1.5 million questions on StackOverflow).

Those that don’t know how to do it well, need to learn, like I said above:

Writing adaptable code is hard, regardless of the framework you use. It’s easy to hack away and make stuff work, but it’s harder to read a ton of information, apply it, and become a better developer. That stuff takes investing time and mental energy.

Testing in my opinion is a fundamental part of writing adaptable code. When you have a large team + a large codebase, you won’t move very fast without testing.

[sam]

Static code analysis, good error handling, etc. seem so much more helpful, to whatever extent they are implemented.

Agree that these are very useful and they are one form of feedback. You need many forms of feedback, which include:

• Static analysis
• Unit testing
• Acceptance / End to End regression testing
• Manual QA testing
• Performance testing
• Monitoring

The list goes on

[aadams]

To me, a major aspect of creating adaptable (maintainable) code, is creating a great separation of concerns. For example, If you separate your domain from your view properly, it will be a lot easier to transition from one technology to another. However if you write a ton of logic in your views, well then you’re screwed - and not just if the view layer technology you’re using changes / is deprecated.

I’m glad you brought this up. You see, I agree to some degree. I mean creating abstractions, like I was use to in the .Net world with C#, you create complexity in exchange for maintainability (and abstractions are great at solving problems in the language too by the way). But maintainability via abstractions – I was on board with that.

Then I decided to build my startup in Node and JS. Well, I first looked at the MEAN stack. There were abstractions to be found everywhere. Everyone was raving about Angular. But it was hard to get up to speed on, and things where in constant churn.

Then one day I ran across Meteor, and the rest his history. No, wait, let’s take a closer look at that history.

Full stack experience. Magic. Reactive. Build your startup in no time. These were the terms being dropped over 1 year ago. I’ll bite, what’s going on here?

After researching it more, I found a world where things were abstracted away from me, instead of me building the abstractions. Sub/Pub/Tracker/Methods/Blaze – easy enough to get up to speed on. No Web Server, sockets, Restful endpoints – just build your idea. Things just worked, and again it was Reactive! And all the shiny new things that seemed just around the corner was the talk.

No talk and no documentation on abstractions. Just an easy to use API and a ton of great packages on Atmosphere. Blaze was great as a template tech, separation of concerns in JS/HTML in et al.

It worked. Maybe it didn’t scale as well as it should have, but I and a lot of others were/are super productive and I have a small business build on this tech. This is not some prototype. With a little work on Tracker and Blaze, scaling and the like could be worked out at some point the thinking went.

Don’t be fooled by what some say, I’ve written a ton of Reactive, Componentized code and Meteor+Tracker+Blaze works amazingly.

Yet, now the talk turns towards something more familiar. Something I’ve heard for 13+ years. Maintainable code, separation of concerns, abstractions, change because change happens. Let me tell you, while I understand the logic, most of this will not make you much more productive, or help you quickly solve business problems, get your product out the door.

Meteor+Tracker+Blaze was fine. It was amazing even. It helped me and many others get our products to market – fast. The bugs could have been fixed. The kinks could have been worked out. GraphQL, which I believe is the right way to go because it will enable SQL and other databases, could have been graphed into Meteor without adopting the Facebook stack. Everyone knows this.

The only reason some on this forum are pitching React and the Facebook stack is because MDG has decided that this is the train they want to get on. They’re not doing it because of separation of concerns, or abstractions, or even because React is the best tech or best choice for you and your business. MDG is making this switch to React and eventually the entire FB stack because they think this will make Meteor more popular with developers – it’s that simple.

And this is fine. Lets help others migrate. Lets talk about best practices now with React. Lets talk about abstractions to help everyone prepare for the next tech change at every level of the stack.

But lets not pretend that this transition is some altruistic endeavor. Lets not get down or critical of others that disagree with our narrative. Lets not get too worked up when others question the prevailing winds or when threads get created that are unpalatable to the standard notions.

[aadams]

Full-stack components are an anti-pattern. When you have to gut them, it’s painful. They erode code reusability and flexibility in times of great change.

And this is just what you’ll get with React. They turned the conversation around and instead of standard separation of concerns, they now say we could tightly couple the JS and HTML-esq code into one. I’ve even seen videos where React guys say that Template’ing like Blaze and Handlebars is not separating the right concerns, yet React is.