The frustration of keeping current

Planet Earth
1

I just had a chat with a colleague about this, and I wanted to post my thoughts (frustrations) of working within the Meteor ecosystem. Though not all of this is about Meteor itself, but the state of frameworks today.

So about 6 months ago, I started learning React, followed tutorials, etc, and felt like I had a really good grasp on things. Then I browse the forums recently and discover this thing with “dumb” components:

const PostList = ({posts}) => (
  <div>
    <ul>
      {posts.map(post => (
        <li key={post._id}>
          <a href={`/post/${post._id}`}>{post.title}</a>
        </li>
      ))}
    </ul>
  </div>
);

And I swear that wasn’t a thing when I learned React not too long ago! It used to be that you’d just have a React.Component full of lifecycle methods, and your Meteor data would be fetched and handled within the getMeteorData method, and now people are even moving away from that and putting data-handling in a Flux or Redux store.

It seems every time there’s a React.js Conf or some other conference, someone throws out a new idea, like “hey, let’s do things this way!” and everyone says “yeah, that sounds good” and goes off and does it on their projects or at their workplaces. And then when they have to onboard more developers on a project, those new developers are scratching their heads, because they’re using old school methods from 1-2 months ago. My current jump down this rabbithole actually started because I got hired on a project where I thought I’d kick some ass with React, and then I find one of the developers who’s more current than I am is using inline styles, Meteor 1.3, modules, etc, and I realized I had some catching up to do. I’ve spent probably 8-10 hours playing catch-up, and I’m still not totally done yet.

I feel like 60% of my effort is keeping up to date, and 40% is actual development work, and that’s frustrating. I get that these frameworks are constantly improving and people are finding better ways to do things, but won’t we ever reach a point where things work pretty awesomely and we won’t have to worry that an app we just started building a month ago and is 25% complete suddenly appears to be architecturally obsolete?

I’d love to hear others’ thoughts on this. How do you deal with keeping current? What do you do about the constant noise coming in? I’d like to at least keep current on Meteor and React. Is there some magical YouTube channel or blog I need to subscribe to so I always know what’s new? I see rumblings about things like GraphQL, Elixir, etc, and I totally ignore them because I don’t want to get distracted by the new shiny thing all the time, otherwise I’ll never get any work done. I’m just one guy, and I don’t have the mental bandwidth to pick up brand new technologies, while also juggling my personal life (not much of that lately!) with work stuff.

Whew. End of rant.

29 Likes
2

Yeah, it’s pretty rough. I guess the main issue here is that you can’t really “know React” or “know JavaScript” since the definition of that is changing all of the time.

I’d say that the situation you described is not so bad - I would definitely expect to learn some new stuff when joining a new team. As for your own projects that become “architecturally obsolete” - you could just not care. All of the stuff from 6 months ago or a year works just fine, personally I still prefer React.createClass to the new stuff.

I guess it depends on how frequently you switch teams or projects - if it’s very frequent, it sounds super frustrating.

2 Likes
3

I guess my switch to Meteor 1.3 is a major move that’s been challenging, because of a bunch of interrelated factors:

  • We now have npm packages natively which is awesome.
  • Now I’ll stop using meteorflux:meteorflux probably, since I can just use redux via npm.
  • Now I have to learn Redux.
  • Now kadira:react-layout doesn’t work, so I need to use react-mounter via npm.
  • Someone tells me about Kadira’s new thing, Mantra. Investigate that.
  • Then I see the below code in @arunoda’s sample blog app:
import loadMethodStubs from './configs/method_stubs';
import {initContext} from './configs/context';
import {initRoutes} from './configs/routes.jsx';
import actions from './actions';

loadMethodStubs();
const context = initContext();
initRoutes(context, actions);
  • Head explodes, because of a million thoughts and questions:
    • Why can’t I just use FlowRouter as I did before, creating a bunch of routes via FlowRouter.route?
    • This looks like it’s moving away from “it just works” Meteor methodology and into Node.js “welcome to hell”
    • I find the initRoutes definition:
export const initRoutes = (context, actions) => {
  const MainLayoutCtx = injectDeps(context, actions)(MainLayout);

  // Move these as a module and call this from a main file
  FlowRouter.route('/', {
    name: 'posts.list',
    action() {
      mount(MainLayoutCtx, {
        content: () => (<PostList />)
      });
    }
  });
  • Fragments from previous head explosion explode:
    • What the heck is this?!
  • What’s injectDeps and why the heck do I need it? I thought I was in Meteor land where everything is simple and works magically!
  • Why can’t FlowRouter.route calls just be outside of any function like in the old days, 2 months ago?

This is some insight into my mental process when I see this stuff. It drives me crazy. And the thing is, this is not fun for me at all. I just wanna build apps. These rabbitholes are nothing but a time-suck.

22 Likes
4

I think this is where Mantra and the Meteor Guide diverge. When we’re writing the guide and when we’ll be updating it for 1.3, we’re going to have a keen eye for exactly the issues you’re describing - managing incidental complexity, setup, boilerplate, etc.

I guess I’d just suggest staying with what you have and not trying to update to the newest thing immediately. Meteor 1.3 isn’t even released yet - I know the React way is to use the newest beta of every single thing, but there is also an option to just keep doing the thing that works.

Of course, it’s up to your team and coworkers to decide how they want to play it. Personally, I’d play it safe, just use the new functionality that benefits me, and follow MDG recommendations closely (easy for me to say since I write them, I guess lol), as those prioritize stability, simplicity, and productivity over all else.

Unfortunately the Meteor 1.2 and the current guide don’t have much to say about file structure and testing, but that’s coming ASAP. Keep in mind that we’re building Galaxy on a lot of these principles, and that app is quite complex. So hopefully we can come up with something that works for a large, complex application, but is also easy to understand.

7 Likes
5

Okay. Let me address these things first.

  • Now we need to use React from NPM
  • So, we can’t use React Layout since it load it’s own version of React. And it’s cause to have two different versions of React. react-mounter is the solution for that.
  • Right now Mantra’s goal is high maintainability over simplification.
  • We may have some boilerplate stuff for now and you may have seen new stuff like dependency injections, containers etc.

Don’t worry, these are the some of the new ideas we took from the react community and apply it to build better apps.
Soon, we’ll be launching a site called Mantra Tutor which is similar to what BulletProof Meteor and Learn GraphQL.
Then, you’ll understand the power of these and why they are best for your app.

  • Then we’ll have some automated tools to make your life easier.

We plan to provide you a guarantee that you won’t need to change your app for the next 3 years, if you follow Mantra :smiley:

10 Likes
6

Personally I follow a few smart guys online, hear what they have to say, spend about 1 hour reading what the idea is, and if it’s good circle back to it months later. Identify key players in whatever ecosystem you are in, follow them.

It doesn’t matter if it’s new - is it going to solve a problem for me? That’s the question. One you can’t answer until the idea has been tested in the wild for months/years.

I tune out the rest of the noise and focus on Taking Care of Business.

2 Likes
7

@ffxsam: I share your frustration. The whole Zen of Meteor for me was the combination of incredible power with beautiful simplicity. Now we have this creeping complexity which is really driven by outside influences, not Meteor itself. I don’t believe that MDG has had sufficient time and focus to abstract away the complexity the way they did in earlier versions. The declaration of the move to React was not supported by the package community (atmosphere.js) and since a significant part of any decent app comes from packages Blaze gets a longer lease on life. Angular feels more and more like the odd man out even though it’s also popular and Angular 2 just adds to that particular complexity.

Lately I’ve been trying to get test automation up to snuff and even just that aspect of Meteor is driving me batty. Cucumber keeps changing (and breaking) faster than I can keep up with.

I started down the path of learning React but to @sergiotapia’s point, it didn’t really simplify the way my app is put together. When @gschmidt announced that Blaze was going to stick around for awhile I basically shelved experimenting with React altogether. If and when a good number of core packages become available as React and React supports a similar, visceral level of simplicity then I’ll come back to it.

When @sashko says:

So hopefully we can come up with something that works for a large, complex application, but is also easy to understand.

That’s a darn good description of the problem ahead of MDG. The value proposition of being able to build an app quickly that supports both browsers and mobile devices and that can scale and grow is huge.

@sashko has also said that Meteor will become “more opinionated” with respect to things like routers. This is an important point as trying to please everyone no matter what router, front-end framework, test framework, mobile target, etc they use has huge costs in documentation, testing, and education of the community. “Supported permutations” have a nasty habit of growing far faster than resources in a startup; success requires a high degree of focus.

5 Likes
8

This is an amazing claim @arunoda!

I’m looking for this type of guarantee as a small business application developer with limited bandwidth for keeping up with the constant churn. If I have to put up with a little more complexity and boiler plate code, in exchange for longer term stability – where do I sign up?

6 Likes
9

Just keep eye on Mantra repo for now: https://github.com/kadirahq/mantra

2 Likes
10

This is some insight into my mental process when I see this stuff. It drives me crazy. And the thing is, this is not fun for me at all. I just wanna build apps. These rabbitholes are nothing but a time-suck.

Mantra is out since monday and not the specification you can call stable for at least a few days(understatement) :wink: - so it’s nothing to worry about, yet. Some geniuses collected their ideas by there best knowledge and other geniuses start to review and discuss them: https://github.com/kadirahq/mantra/issues
Nothing is set in stone yet, https://github.com/kadirahq/mantra/issues/3

I’d love to hear others’ thoughts on this. How do you deal with keeping
current? What do you do about the constant noise coming in? I’d like to
at least keep current on Meteor and React. Is there some magical YouTube
channel or blog I need to subscribe to so I always know what’s new?

You don’t need to keep current if everything is working :wink:
We use blaze in one of our apps and we have no intention to update it to react.
Even when using an outdated version of meteor you are miles ahead in comparison to some other freameworks, so you can simply ignore the voice. Keeping current with meteor and react isn’t a bad idea but you have to decide if the new shiny thinks are worth the work, or if you’ll wait for the next release.
I don’t know a magical youtube channel, but at following:
https://voice.kadira.io/


was a good suggestion, at least for me. Listening to some noise in the irc channel also can’t hurt.

Regards,
Lukas

2 Likes
11

Well, I’m sorta forced to update when I join a team using Meteor 1.3, which is my situation. But I realize I can’t learn all the new shiny things at once. This might warrant a separate thread, but I think realistically where I’d like to be:

  • Use Meteor 1.3, React, NPM modules, import/export
  • Use Redux (the official NPM package) and figure out how to wire it into Meteor/React
  • Optional: Stop using the ReactMeteorData mixin, find some other way (whatever it may be) to deal with reactive data sources

I think that’s a fairly realistic list. The last one is optional, because not using the mixin most likely requires a lot of work trying to piece something else together. I could probably use react-komposer actually, with its composeWithTracker function. It’s just a totally different way of structuring the app that I’m not sure I’m ready for right now.

1 Like
12

Thanks @arunoda. How is this going to compare to the Meteor guide?

13

To me it’s two different things.

Meteor Guide is showing best practices related to Meteor in general and it’s the missing documentation for Meteor we always wanted.

It’s amazing.

On the other hand, Mantra is not a guide.
It’s a spec on how we architecture a Meteor app with 2 goals in mind.

  1. High Maintainability
  2. Future Proof-ness

So, we use a minimal set of tools/packages and a very strict set of rules. And we choose React and it’s design patterns and where the community is heading.

Then for the once the app is architectured, you can use the most of the recommendations does in Meteor guide. They may be some places we contradict with the Meteor Guide. (But I guess that very minimal)

We’ll have a tool called mantra-linter to check whether you are following the mantra spec or not.

3 Likes
14

I think that at some point you just have to say, screw it, I like to do things this way, and forget the possibilities for a while if you actually want to get something done.

Once you have your setup up and running, and feel confident this will get the job done, then off we go to productivity-land where your hammer doesn’t grow new heads every other week, because you are in charge of your hammer-version!

Sure, if your hammer has a serious flaw that compromises the security of your house, go ahead and update that one thing, but do finish that house afterwards with the other tools you know works.

You have now proven that either this toolset works as intended, and you don’t actually need to change for a while, or you have discovered something that could be better, and you change that. No need to throw out the baby with the bathwater.

I have for the last 3 years worked on a highly interactive web application written in Django and (gasp) jquery, that is now going to market and is being well received. It may not be as sexy as the latest React/Fluyx/flox/FlaxxrrFlexPackr, but I think it demonstrates that a well worn knife can still get the job done. “Old school” react (more than 2 months ago) still works like a charm.

8 Likes
15

What happens is people see the react vs blaze vs angular 2 graph and are like “OMG angular 2 rendered .0000002 seconds faster OMG I need to use angular 2. App users will leave if performance isn’t good I need angular 2”

The reality is that – yes-- your app must perform, but no normal human cares if you template renders in .0000002 or .0002 …

I use a todo app that ALWAYS takes like 15 seconds to load… todo apps are pretty much the most substitutable app you could ever think off (I mean, I could build my own todo app of this caliber in a couple days)… but I’m still using this todo app.

But devs are like… well I could build the same thing with blaze in two days… if I use react it’ll take me a couple weeks… but I’ll get that .00000002 in performance.

The reality is normal non-developer humans are not going to live and die by that time difference found in the blaze/react/angular2 graph (or similar graphs). The majority of your app’s users don’t care and only expect data on the wire speed with a narrow number of features (likes, messaging, notifications, etc.).

Meteor is awesome.
Blaze is awesome.
I’m sure react is awesome but let’s not get blinded by the light here.

I think the developers get a little lost in the weeds sometimes.

4 Likes
16

Personally, I think the new container pattern in react looks butt ugly. I like my mixins.

4 Likes
17

I agree. Some people does not like it.

1 Like
18

Thanks @sergiotapia for this strategy. I have been frustrated myself and was thinking along the same lines

19

Thanks @arunoda for the guarantee and the awesome work. I have been planning to launch an app as a solo developer but really frustrated with all this changes.

I am really looking forward to Mantra and following its patterns

20

Yup, I share your frustration to some extent. My strategy for this? Well, I just ignore the new trends until I get the feeling they became stable enough. I had a sneak-peek into React Meteor when 1.2 came out, but quickly decided that it is not “ready for productivity”, at least for me. So I stuck with Blaze for the time being, although I knew that MDG clearly stated that React would be the future.

I switch parts of the stack only if I see a clear benefit from a “business” perspective. Better scaling of Meteor would be one thing, another would be reduced app loading times (e.g. by hot loading of modules). But even these benefits won’t convince me if my development speed degraded significantly.

3 Likes