Angular, React, and Blaze

announce
82

@sashko Sorry, I didn’t understand what you mean…

83

Running them from the local file system like we could do with standard Meteor packages. That way, we can run a PR that wasn’t accepted yet or modify things to my liking.

There was also a request for here it a while ago:


Edit: reading over it now, it looks like it was implemented on the app level. Did not know / have not tried it, but looking forward to trying it.

1 Like
84

Wow! A local webserver on a smartphone. :+1:

While I am truly impressed with the idea and endeavour, I am scratching my head to see if it’s not overkill.

But I can see the rationale, mobile sockets can be spotty, and may not update real-time with the online backend. The only time we implemented it was with a native app, so can’t tell if the webview component is good at it or not. So having a local persistent copy that gets updated when available is a solid idea.

But this does get me depressed for other platforms :smile: – what do we do to properly support windows phone?

1 Like
85

In case I didnt miss the answer already, I would like to ask again, is MDG planning to prceed developing Blaze? (after figuring out and measuring all community and internal idears & suggestions)

1 Like
86

looks like blaze will be kept around, but not developed much

87

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
88

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
89

it looks like you misunderstood. Blaze will be maintained, but not developed.

Can someone else contradict me?

1 Like
90

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.

91

@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
92

@arunoda Is Mantra simular to Flux or Redux?

1 Like
93

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
94

@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
95

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
96

The sick feeling I’ve had in my belly since reading the last article has settled.

97

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…

98

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
99

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
100

I think it’s worth making the distinction between a few things:

  1. 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.
  2. Yes, the DOM has an API for doing stuff: Element, document, etc - with stuff like myElement.addEventListener and 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
101

I’m curious now… What would a ‘native implementation layer’ look like?