Currently Blaze does not support HMR. I’ve been working on a Meteor compiler for single file Blaze templates, which will support HMR, but it won’t provide HMR for existing Blaze templates. After finishing this compiler I plan to look into adding HMR to Blaze.
HMR does work with dynamic imports.
It doesn’t do anything special in that case. All of the modules between the one that was modified up to the one that accepts the update are re-ran to use the new value of exports. A module should only accept an update if parent modules don’t use its exports, or there is another way to update the value the parents imported.
And that’s exactly why I’m 0% exited about HMR. The majority of us is still using Blaze in our Production apps. Once again Blaze isn’t getting the attention it should deserve from the number of Production apps which are using it.
People that write fun apps or non commercials ones always change their Frontend framework like underwear. For those of us who run commercial apps in Production there’s no need, the cost of changing vs the benefits is just not making sense. Besides Blaze isn’t that bad at all, just take a look at how close Svelte (the last great thing) is to Blaze.
We’re using an Electron app anyways so we might be a special category anyways.
Based on latest frontend survey, more than 60% are using React or Svelte. And those are most dominant few technology on the web, so I think this is the best feature happened to Meteor in years.
In Production apps? I highly doubt it and like I wrote that is what is misunderstood. Felipe just wrote that Tiny is aiming at the businesses using Meteor, not those “oh look there’s a new framework, let’s try it out” community.
Business spend their time on improving their product, introducing new features and fixing bugs.
Which business let’s their employees spend precious time on checking out all those shiny new things that popup every week because it might turn out to help improve their project by 1%?
What would a switch to Svelte or React mean for me as a business owner? I can tell you, minimum 6 months of work with very little improvement and no additional benefit for the customer.
Going with React, Vue or Svelte would significantly increase your chances of getting good developers to join your team. If you run an actual business, that’s critical. Like it or not, most devs prefer not to be forced to learn something that they feel will not benefit themselves in the long term. And as things stand, good devs are already in short supply. It’s hard enough for companies to attract quality people anyway. Trying to do that with Blaze will just make things that much harder.
The front end wars came and went. Blaze is decent, but got left behind. That is just the reality of it. It would be a bad decision for Tiny to try to out-compete React, Vue or Svelte with Blaze. If you can’t beat them, join them. Staying front-end agnostic is the reasonable option for Meteor. I’ve said it multiple times - the Meteor-Vue integration is just about 2.5k lines of code (a few hundred for tracker, the rest for build system). Meteor should just focus on maintaining those integrations and leave the front end libraries to duke it out between themselves.
Btw, I’m not saying you should switch you existing project to Blaze. Blaze works. But it absolutely would not make sense to start new projects on it.
Hmh, you’re proposing I’m investing 6 months of work (and pay) for a good developer to move away from a working Blaze environment to one of the three mentioned?
For what benefit? To attract good developer?
This all doesn’t make sense from a business point of view and if that’s how you run yours I wonder how you break even.
One doesn’t spend money just on the purpose of employing someone. Especially now with the change in spending behavior that is already affecting most businesses.
Maybe you misunderstood that part but our app is in production and there is very little development needed on Frontend (Blaze works perfectly fine). The FE app is optimized to handle thousands of connections should we ever get there.
Our FE runs on Electron btw, so we have our own Windows, MacOS and Linux app for our customer. Works all in the same wonderful way as the web, with auto-updating.
It’s the backend where I’m still working on bugs and do most of the work.
@a4xrbj1 I think this is a clear statement that HMR will also get into default Blaze. I think the flare compiler is a nice refresh to Blaze and I for myself can wait a few more weeks/months for HMR getting into Blaze. Improving Blaze itself is also on my roadmap and @filipenevola also stated that future contributions to improve Blaze will be reviewed and merged.
Agree with you but that’s not what others have stated here and to which I responded.
Like I mentioned, there are devs here that do have commercial apps developed in Meteor and in production and are running a business to make a profit. Then there’s the rest that doesn’t qualify all the conditions I’ve just stated.
There seems to be a very different view between those two groups because these groups have different goals and reasons.
But anyways, I guess even the last one should have understood my POV as a business owner now so I can rest my case and go back playing E:D
I understand your point, we are a small research team and our software grew since 2016 and we simply can’t replace the frontend without literally cancelling our project. I am also happy that Blaze is working stable since the first day. However, I think choices like tree shaking and HMR are crucial to regain traction and from outside of this community, making Meteor sexy again.
That said, we need to also attract new developers, to learn Meteor and so they can also start new businesses.
But to your point about Blaze, we are not leaving Blaze behind, HMR is going to be a reality for Blaze pretty soon. We got you covered.
About React, I believe React is the default choice for web development today and I believe it needs to be the default choice in a new Meteor app as well BUT this DOESN’T mean that we are not going to support and improve Blaze, or that we are going to not support Vue, Svelte or whatever comes next.
We understand that new technologies will always emerge and we need to keep an eye on them but also focus on 1) Businesses in production and 2) Main stream technologies.
Interesting fact: My name is with I. Filipe and not Felipe I really don’t care but my wife does hehe.
Ah, this is a great list. Short, concise, and to the point.
It is really awesome that Filipe (with an I) has hands-on business experience using Meteor, in addition to what seems to be a deep, pragmatic understanding of what the tech is all about.
Speaking for myself, every step Tiny made thus far is exactly where I’ve hoped Meteor would go. I think this stems from the shared perspective and experience Filipe has with the community. And speaking of community, zodern solved the biggest Meteor pain point by enabling HMR, so kudos to that, it is really impressive how it works out of the box.
I know there is a lot of hard work behind Meteor 2.0, so keep it up
Firstly, thanks for all the effort in moving Meteor 2.0 forward! I’ve used Meteor since 0.2 I believe when they had the / wrists quote on the initial web page and I am continually grateful for the support, especially in the post MDG world with Tiny.
That said, I’m seeing an issue migrating from METEOR@2.0-beta.4 to METEOR@2.0-rc.1:
Uncaught Error: Invalid hook call. Hooks can only be called inside of the body of a function component.
This is happening wherever I’m using hooks, with the first hit being useTracker inside my main <App/> functional component – no issues when running using beta4. I have dug into this quite a bit already and haven’t been able to find the issue, but I’ll keep digging.
Interestingly, trying to run the app on 1.12.1 (meteor update --release METEOR@1.12.1) gives me the below error so I wasn’t able to confirm the working hook there either:
Well - I just meteor create test-react --react and noticed in the new project the .meteor/versions listed react-meteor-data@2.1.4 but my main app after upgrading to rc.1 still listed react-meteor-data@2.1.3 – I changed that to be 2.1.4 and viola, my hook error went away.
