I guess in my mind there’s a cognitive dissonance between:
The biggest problem with JS right now is that there are too many ways to do things, we just want to present the one best way, and
We should let people decide if they want to import code via modules, or have it auto-load symbols into the global namespace
I am just responding to your statement that having to import packages is overload - other than certain core parts of Rails and Meteor, it seems that most other development platforms require imports everywhere, and people reap the benefits as well as living with the consequences.
Right now we jump through crazy hoops in Meteor to do custom namespacing by attaching things to objects (Meteor.loginWithFacebook), controlling load order via nested directories, etc. So not using modules also has costs. Given only one option, which I think was the main point here, I would pick modules over something else every day of the week.
@sashko, you’ve spoken to the non-optional module system, but what about the following quote from @faceyspacey?
I don’t know a thing about intimidating terms like non-optional module systems, react, flux, redux reducers, action creators, component stores, provider context, graphql, relay… will I need to know these things at some point soon or be sidelined to Meteor 1.1.0.3 or 1.2? Will I need several courses on this tech in order to use Meteor in the future?
Autoload into global namespaces for all or selected modules (and/or Meteor packages) could always be a configurable option in (something like) package.json later? Having to explicitly import in the interim seems fair, and it should be fairly simple to avoid subsequent conflicts with autoload (i.e. require once). Modules seems most pressing… I think most would want to do explicit imports until something like rollup comes to handle imports automagic- and economically. Even then some would want to do explicit imports, just for overview, or if using something like rollup adds to build time.
Yea, i figured that’s what you were actually responding to. …given only one option, I’d pick the same as you: standardized imports/modules.
and if:
is unnecessarily increasing complexity to too high a point, I’d also say drop it.
But, if somehow we can reconcile the “cognitive dissonance” between being the “one best” way vs. added complexity from modules, via a strategy, we should. If you get a chance, let @benjamn know my proposed strategy that we statically detect which files use modules, and if they don’t auto-import them. Not sure if he read my comment on his thread. He seems to be busy with higher priority fundamentals. You can probably better find an appropriate time to bring it up to him. …The other main idea there is: if you remove the autoimport package, Meteor generates your main.js file to contain all the initial boilerplate setup so automatic importing of core packages is reconciled with manual importing–that’s as opposed to unnecessarily mixing both paradigms so that application code is manually imported while core packages are automatically imported. If we can get Meteor code to look like a standard NPM app, e.g. the first thing you see in the entry file is express configuration, it will go a long way to changing the perception of Meteor.
Here was my article with all my proposals on the Meteor 1.3 module system:
And more to the point… should you need to know these terms?
Now don’t get me wrong… I’ve long argued for functional programming, and regularly use D3 and Nightwatch method chains that would make most novice programmer’s heads explode. I’m not a React hater. And I’ll probably be migrating like 80 packages to React eventually.
BUT. Do the physicians I work with need to know this stuff? Do the UI/UX designers? The database admins? The biostatisticians and clinical analysts?
And this is where the React hype is getting in the way of people’s businesses. It’s all well and good that there are improvements on the way to improve the rendering layer. But look at the relationship between docs.meteor.com and the sample apps (Leaderboard, Todos, Parties). And then look at what the React API brings to the table (not much).
I have the same conversations with the database geeks who get too focused on the data warehouses, and the clinicians who don’t understand the tech, and so forth.
What’s the significance of the relationship between the docs and samples? What, it’s extremely easy to get these applications to 0 to complete? I’m looking over the Todo application now, and the code and markup is easy to follow and just make sense…
This is what I’ve been scratching my head over, especially after reading the React feedback from devs that are actually using it…
It’s also the reason I went back to Schmidt’s video from earlier this month and wrote a post trying to make sense from a strategic perspective – because from a technical perspective the move to React wasn’t adding up to me. Going back over the video didn’t help much, but I decided to post my findings anyhow.
I think the above means no Blaze 2.0 and no Blaze overlay despite what Schmidt, the CEO of MDG, states in this opening thread.
As far as I know, MDG never ended up posting an official thread explaining the rational.
This is all I could find further down the thread linked to above, all unofficial:
So @evanyou thinks it would be great for Meteor Developers if someone builds Blaze 2 (in this case @faceyspacey), but MDG isn’t going to.
And to what value he’s talking about above? I think the following provides a hint:
[quote=“evanyou, post:7, topic:14757”]
In short, I think our strategy will be align with React[and FB] community’s best practice, but provide opinionated (but compatible) configuration/components/guidance as part of the framework.
[/quote] [Emphasis mine]
To me this signals MDG’s medium-to-long term goal is to transform Meteor, from what it is today, into the sticky-interconnectivity for the FB stack.
And the above to me signals the beginning of the end for Tracker as we know it.
Also, I think the world he’s talking about above is a Facebook, functional programming style, world.
This is not just a small technical change to React on the front end. The shift to React signals a tectonic change to everything we know that is Meteor. We should be thinking in terms of what won’t completely change, instead of what will change.
I think after the transition Meteor will be almost unrecognizable from its current form circa early 2016.
True, weird that it’s so quiet from them. Most commented thread on the whole forum, and only a handfull of (contradictary) statements here and there… sigh.
Wrong. You don’t need to know redux to use React and Meteor. You just need to add getMeteorData() to your react component and you’re done. It’s quite beautiful and simple.
Sure, I also heard “Tracker is going away”, BUT that is just long term ideal, the fact is that Meteor reactivity works just fine alongside React, I proved it for myself.
@awatson1978 I get your concern about learning curve, but the fact is, if your UI/UX designers aren’t smart enough to figure out JSX in about a day, hire new ones.
if someone would bother, it also wouldn’t be impossible with meteor and or babel+webpack to write a .html support file for each relevant component, and have it slurped and transpiled and included as the render section at compile/bundle time.
Same for helpers, events and hooks if need be. However, they should really want it. Take Redux, Relay, etc into account as well, although they can also discard it and abstract freedom and power away from the developer to gain a certain syntax and development style.
But a word of the wise is not to over-react right now, there is a shake down in place, and people will have Eureka moments, designs, patterns and approached will appear and be refined, knowledge will diffuse, and soon those who were against will be protecting the new status quo.
I just see a lot of FUD about React and Meteor’s new chosen direction being thrown around on this thread, and it’s pissing me off. There’s no good reason to be afraid of React, or that Meteor will fall apart because MDG decided not to continue developing Blaze. This kind of dialogue actually is pointless and hurts the community.
This is not FUD.
Blaze is dead.
Tracker will die.
Pub/Sub will probably die.
MDG doesn’t develop a JS framework anymore but a distribution of various (and changing) JS technologies + a hosting solution.
