looks like blaze will be kept around, but not developed much
This sounds great! This is also why it would be great to have a roadmap for Meteor back up soon. I feel like you drop great gem announcements in random threads across the forums that not everyone always sees. Having these centralized somewhere would be great for everyone and also provide a great opportunity to give feedback.
5 Likes
I do not agree that Blaze should be a special 1st class citizen, and others should get what’s left on the table. That will never work.
Blaze is to be treated and maintained at the same level as react, angular, etc.
That is also what gschmidt communicated, unless I misinterpreted his announcement.
4 Likes
it looks like you misunderstood. Blaze will be maintained, but not developed.
Can someone else contradict me?
1 Like
AFAIK the future of Blaze is still uncertain. We just don’t have the complete picture at this point. A request for clarification has been posed to @gschmidt, with no response as of yet.
@gschmidt, thanks for your post giving the community some sense of direction and what’s to come.
The pertinent question to me however hasn’t been addressed. What about integration with React Native? (not React “web”) I’ve been there, done that with Cordova (with Meteor) and that left a sour taste in my mouth, and not enough for a mobile app I’m building. React, Angular and Blaze are irrelevant since all are dependent on Cordova for mobile apps. I’d love to stick with Meteor, but without RN integration I’ll have to go with something else like Parse for my apps’ data and infrastructure needs.
Thanks in advance if you can address any roadmap for React Native integration.
1 Like
In one way you can think like it’s very similar to how data flows in Flux. But again, Mantra is more than that.
Mantra show you how to layout your app and where to put stuff. Also how to test stuff and etc.
In the state management later, mantra allow to use a lot of technology. You can use Redux too.
See more: https://kadirahq.github.io/mantra/#sec-State-Management
4 Likes
@arunoda Just wanted to say that react-komposer looks great! I’m stoked that it’s an NPM module so I can use it in a project where I am using react, but a different back-end. It’s a simple interface, yet it provides an important separation of concerns: where our data is sourced from vs. how we present and interact with it. Thanks!
3 Likes
Yeah. That’s the way where the React community is going after.
I think containers will be more popular in React community soon.
1 Like
The sick feeling I’ve had in my belly since reading the last article has settled.
My wish and hope is for a native integration of the presentation layer.
If I use Bootstrap or Material components; I should be able to do that without caring if Meteor is using Angular, React or Blaze as a controller.
I know this is overly simplistic and a bit ignorant, but keeping the presentation layer ‘native’ while Meteor’s internals are massaged into place would ensure that we can build and maintain our Material or Bootstrap views, then configure the controller and model layers as the Meteor stack evolves…
I think this is basically impossible. I haven’t put a lot of time into investigating whether this is feasible, but my initial reaction is that every abstraction of this form will be seriously leaky.
For example, how to you get your data into the view? Is it with {{ ... }} tags? That’s already coupled to a specific view rendering technology. How do you attach event listeners? There’s no “Bootstrap event listener language”.
1 Like
It might be leaky, but it’s the basic concept of what the DOM is for… a compilation point that normalizes different rendering technologies.
Keep in mind that the DOM has been around for a long time… for a decade, it was common to render data from Apache servers, ASP servers, Tomcat servers… think React/Angular/Blaze is bad? At least they’re all in the same language. The DOM was formulated as a way to switch between different (server-side) rendering technologies. And it supports client-side style sheets and presentation layers just fine.
Polonski makes an entirely reasonable point (and is what the BlazeReact/Sideburns project is basically all about).
2 Likes
I think it’s worth making the distinction between a few things:
- DOM != HTML - HTML is the abstraction that allows different server-side technologies to output stuff that browsers understand. DOM is just the API for JavaScript specifically to interact with the browser’s view tree.
- Yes, the DOM has an API for doing stuff:
Element,document, etc - with stuff likemyElement.addEventListenerand friends. But these APIs are so painful that basically nobody uses them. This is why people use Angular, React, and even jQuery.
If you are suggesting that we should use the DOM API as the way to interoperate between Angular/React/Blaze, then I would suggest that removes the main point of those frameworks in the first place, which is easy updating of the DOM and attachment of events.
If not, then I don’t know what you mean by DOM.
2 Likes
I’m curious now… What would a ‘native implementation layer’ look like?
Fair point; I tend to use the two interchangeably (in the same way that Coffeescript enthusiasts describe Coffeescript as just being Javascript).
To be a bit more exact, I suppose I’m referring to the the HTML to DOM rendering process.
Anyhow, the DOM differs slightly between browsers; which is the point of using the HTML abstraction and compilation point in the first place. By focusing on writing well formed HTML, we can run on different browsers using different rendering technologies. Swapping out an Apache server for a Tomcat or Node or Ruby server, and keeping the Presentation layer the same… that’s pretty standard fare in the IT consulting world.
The underlying issue of course is that Angular, React, and Blaze serve different markets and are designed for different kinds of products. Websites vs webapps vs networked mobile apps. There are differing assumptions around the need for interoperability vs native performance.
1 Like
At this point, I thought as much too. Although we could push the envelope a little?
Stuff like this would need to be taken care of by Meteor’s internals where configuration would determine whether you’re running Angular or Blaze or React. Logic inside the {{...}} tags is taken care of by these mechanisms, which would use its configured controller framework… maybe{{ m-if m-that == 'nonsense' }} ... {{ /m-if }} …?
This is very pie-in-the-sky shoe-horning another-cog-in-the-machine stuff … But who wouldn’t love to build their presentation layer only once and then see the stack under it evolve without worrying about its evolution path…
1 Like
This is basically what Blaze does - implementing a system like you are talking about necessarily requires something at least as complex as Blaze.
3 Likes
Yes I thought as much. . Although this one would encompass being able to ‘configure’ which controller framework you want to use and be able to swap between them as the stack evolves…
Anyway, I won’t push the envelope foaming and spitting… But this abstraction would give Meteor another layer of fudgy goodness. 