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.
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…
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.
Honestly I think the easiest solution is to just not care. Write some code in Blaze. Later, if you feel like it, write some other code in React. When you feel like it, migrate your Blaze code to React. Honestly shipping both Blaze and React to the client is not a big deal at all, and writing a 10-line function to call one from the other isn’t hard - in fact we already have one to use React components inside Blaze.
Sorry, which one are you referring to? Also, is there a MDG source of instruction for this type of work? When I get the cycles, I’ll need to start swapping out portions of a Blaze template into a React component as a test. Do you recommend waiting for 1.3 or some future version after that to drop before starting this process (I’m still on 1.1.0.3)?
True. This way you get to play with the different frameworks as needed. Each has its nuances.
There’s still that little voice inside me niggling at how cool this would be. Having UX/UI guys dealing with a single set of Material components inside layouts and all the presentation bells and whistles would rock their world. The code guys would not need to worry about jumping in front of the UX/UI work to update their model and controller mechanisms. For instance; Blaze could be adopted for a while, but then Angular2 would replace Blaze. . All the while the presentation layer guys are all blissfully unaware…
It would basically be the templates containing Material or Bootstrap HTML components (and CSS). Logic and data inside the template handlebars would be standardized and not change as different controller frameworks are adopted.
To illustrate, in Blaze I’d have to do this:
`
{{#each parties}}
{{name}}
{{description}}
{{location}}
{{/each}}
`
To then update my Angular2, I'd have to change these templates to this:
`
{{party.name}}
{{party.description}}
{{party.location}}
`
So what I'd be hoping for is to do it once in one template , then that would be the end of it.. For instance something Blaze-esque:
`
{{#m-each parties}}
{{name}}
{{description}}
{{location}}
{{/m-each}}
`
This syntax would then call Blaze to work.
I would then have the UI/UX guys adopt this template as their newborn child.
In the background I might now want to now switch to Angular2. This would mean updating Meteor, removing Blaze making TypeScript conversions etc…
This update, however, would not affect the HTML templates. So the m-* syntax is still used it’s just that now it is asking Angular2 to do this work and not Blaze.
I realise this is inserting a massive layer in the middle, but it would make everyone’s lives a lot smoother as Meteor goes through its growing pangs.
Well, swapping Blaze to Angular2 brings us closer to ES6 with some stricter enumeration in TypeScript classes. Angular2 introduces many performance enhancements as it updates some of the fundamental ways in which it renders data.
It would be of great benefit to be able to pick-and-choose the controller framework here and I guess that’s why this thread exists. It would be even better if we could pick this framework without having to refactor the presentation layer…
I’m not trying to be a contrarian but rather am trying to better learn about this strife with separation of concern in SPAs.
To be fair, these are all server-side rendered pages that were mainly static with limited dynamic parts and are thin clients.
IMHO solving the problem of complex user interfaces should look towards .NET desktop and Cocoa methodologies (thick clients). Clinging to methodologies that were made when thick web clients were the standard doesn’t seem like the right mindset. (keep in mind I don’t have much experience with Cocoa or .NET desktop apps).
I haven’t done much UI programming with Cocoa so perhaps i’m off base but from what I remember you would use C and logic in the view files to manipulate the UI.
Models were kept separate as well as the view controller to handle side effects and general glue.
React with ‘pure components’ + Redux seems to parallel this the closest
const Post = (props) => ({
<View>
<View>Name: {props.name}</View>
<View>Age: {props.age}</View>
</View>
})
// --- Actions ----
PostActions.addPost = (form) => {
makeSideEffects();
return {...}
}
// ----- Data ------
AppState = { // single source of UI data, if this changes UI updates
commentIsLoading: false,
comment: [],
posts: [{name: 'Jane'}, {name: 'John'}],
postIsLoading: false,
...
}
@awatson1978 Doesn't this align more closely to other thick clients? (you seem to have a lot of experience). Perhaps i'm off base but it seems like web pages and web apps are different things that have different problems.
Thick Clients for a long time have tried to have various independent languages to define the UI. The pinnacle for Microsoft was WPF, which has an HTML like markup language with some quite sophisticated data binding. They then created tools for designers like Blend which were independent of the code.
One of the key ideas of having an independent UI definition was you could have independent tools to play with the UI. Which allowed things like visual designers and localization.
I don’t think we should look towards thick UI, but learn lessons from it, but I don’t think it really solved the problem that well.
i just find that most discerning developers suffer from a degree of “analysis paralysis” or perhaps “refined taste” lol that mandate that they at least start out with a plan that involves a stack of technologies that feels cohesive, complete yet succinct that they can be proud of. Who’s setting out to build an app right now saying to themselves: “ok, i’ll combine Blaze for this, React for that.” Nobody wants to do that. And it may in fact end up being easier than what they end up doing lol, but if you have any sort of “pride” lol, you won’t let yourselves do such things on the onset of your project! My perspective is the smart decision (for 80-99% of all cases) is just to go pure React. @sashko there really is no way to put it: right now is a horrible time to start a new project. Absolutely horrible. Not just in Meteor, but within the entire js/NPM ecosystem. A year from now I predict everything will settle down, as this floor (the javascript layer) of the software building will be complete; and we’ll be on to new problems (hopefully and finally Bret Victor stuff).
Relay needs to complete itself and take the place of Redux as well as add subscriptions. Once that happens, Redux doesn’t matter anymore. Right now Redux is basically your only option for client/server state synchronization, but it’s only a stepping stone. Relay isn’t complete. It hasn’t grown into what it will be yet. Therefore we’re in a state of flux lol. My recommendation to everyone is to spend the time leveling up your skills. Study Elm, ClojureScript, Haskell, and Cycle/Observables. And of course how Relay works. Relay is the right model. It just needs to be expanded to include client UI state like Redux excels at. Om Next in ClojureScript is already doing this as well as full stack time traveling! In short, Redux is a subset of what Facebook’s stated goals are for what Relay will become.
ps. @sashko what conclusions have you come up with in all the scouting/research @gschmidt mentioned you and Justin Santa Barbara have been up to? Would love to hear so we aren’t spinning our wheels on the same thing. Perhaps MDG hasn’t started developing any new APIs or, if they are they’re keeping it a secret, but I was thinking about it–and as I started to describe earlier within this thread–the main driver of any fanaticism you may sense on my part (and by many other proactive meteor developers) is: we do not want to build the wrong thing. We do not want to build Meteor packages meant to help the community that MDG ends up creating themselves–that MDG does perhaps better or simply because it’s coming from MDG is more likely to become the standard way to do the given task. What I’m saying is: there’s more than just noise regarding Blaze (I’m over it)–there’s some of us that genuinely want to contribute to solve the community’s problems, but don’t wanna waste time doing something that won’t align with MDG’s ultimate plans. As it is, that basically already happened to anyone (myself included) that has built a Blaze package recently. It’s for reasons like this that we see developers like @arunoda making “specifications” and smaller auxiliary libraries, rather than making bigger bets on more foundational toolsets we need which take a lot more time to create (e.g. a Relay implementation). …I don’t wanna do anything with Redux–cuz after seeing what Om Next is up to–I know Redux is garbage. But Relay is different. It’s larger. It has a way longer shelf-life if it incorporates the best of Redux under one roof. This is an opportunity for Meteor to jump ahead and truly join the React ecosystem by nailing a Relay implementation. Finally, Subscriptions is the cherry on the top, which once again nobody outside of Meteor is giving enough attention! Meteor is poised once again to be the leader of “subscriptions” if it gets going on a Relay implementation ASAP. The fact that the specification for subscriptions is not finalized is the perfect opportunity for Meteor to get ahead. We don’t need to wait for the spec. After all, it’s just a spec! The hard work is what’s going on under the hood–we can mold the interface to the precise spec at the end. You may find out that you created the spec that Relay/GraphQL ultimately went with! …When are we gonna get the discussion going for Meteor’s Relay(-inspired) implementation?
I’m in the Meteor camp for better or worse (the ride has been good for the most part). AFAIK MDG has not spoken on the topic of the data pipeline they plan to utilize with React.
Now that it’s all but plainly said that Blaze will be mostly frozen as it is today in favor of React and Angular, I will need to eventually switch to React.
I for one don’t have the cycles to investigate all the technologies (Redux, Flux, Relay, GraphQL), as I’m steadily building upon the software I wrote (Meteor+Blaze 1.1.0.3) with features and bug fixes. Therefore, I will just hold off on React (outside of conversion testing) until MDG decides what data-pipeline et al we should use and writes documentation to support it. I have a hunch this will be sometime after the 1.3 release.
I just want Meteor+React to settle down more, for MDG to figure out what data-pipeline they’re going to use, for MDG to figure out the best patterns and practices, an Autoform replacement, Bootstrap integration, how to properly integrate all this tech before making a move to React.
:shrug:
I’m more-or-less on the React bandwagon, so I don’t see all that much strife. But I suppose I’ve sort of staked out a position pulling up the rear somewhat. So, to speak to that:
From the IT administration side, an IT department might have any of the following tools or utilities running on browsers in an enterprise, each of which is expecting to fiddle with the webpage and browser a bit and expects the separation of concerns:
client-side accessibility stylesheets (large fonts; stylesheets for color blind users, etc)
media stylesheets (print, brail, tty, projection, tv, etc)
ad blockers (display:none)
3rd party widgets (feedback, polls, banners, menubars, etc)
web crawlers
screen scrapers
testing harnesses
From the development side, a development team with existing toolsets is liable to run into any of the following issues:
color coding
linting
autoformatting
existing code generation tools
existing development processes
recruiting & staffing
The HTML/CSS/JS separation of concerns supports all of those things (and more).
We’re in agreement that React is generally good technology (minor warts aside) and probably the way that the industry is going to go. There’s just a lot of pragmatic realities of day-to-day work in an enterprise that Spacebars provides compatibility with. Conversely, React is much more focused on building a great app experience (for certain definitions of ‘great experience’), and is willing to break compatibility with some parts of the broader IT ecosystem to get that app experience. :shrug:
Anyhow, React + Spacebars seems like it’s a winning combination for my client’s needs that doesn’t require retooling, pipeline changes, retraining, or breaks 3rd party tools. Looking forward to giving it a try next month.
Yea, that’s basically the only smart decision. If you’re not forced to start a new project now, find any way to prolong it. We’ll have a way better idea of how things are gonna look after Facebook’s React Conference. The keynote is by one of the GraphQL creators, Nick Schrock. Hmm, i wonder what he’s possibly gonna talk about?? My bets are on something that makes you wanna use Relay and GraphQL (instead of Redux and whatever way we were doing before then). After all, GraphQL’s purpose is basically to feed into Relay. It’s not the other way around. Relay is the whole enchilada–GraphQL is just a means to an end. Anyone willing to make a wager against my prediction, I’ll put my money where my mouth is–that’s what’s going down at React Conf. Can’t wait to see what they got for us!
