Let's talk about deprecating spacebars

I know the feeling, generally, I’d convert everything to HAML but sometimes, ERB was just more sensible. Kinda like SASS vs SCSS. Sometimes I just want to paste something. :wink:

I think so, I mean, look at the generated template output:

Template.__checkName("about");
Template["about"] = new Template("Template.about", (function() {
  var view = this;
  return HTML.DIV(
    {
      vertical: "",
      layout: "",
      center: ""
    }, 
    HTML.DIV(
      {
        "class": "content"
      }, 
      HTML.Raw("<h2>Title</h2>"),
      Spacebars.include(view.lookupTemplate("content")),
      HTML.getTag("some-other-element")({
          "class": [ "other" ],
          someproperty: function() {
            return Spacebars.mustache(view.lookup("currentEmail"));
          }
        }
      )
    )
  );
}));

Yes, it’s verbose, no this doesn’t have to be the layer we interface with.

It does however feels a bit weird that this API is interfacing with Spacebars, I mean, shouldn’t that be under Blaze? This already looks pretty close to something pure-javascript based. I think we could benefit from a layer that makes this great for components, it just needs some syntactic sugar and polish.

This is just my two cents, I like most other people would still want both, but I’m writing less and less static html these days, I write applications, not blogs :wink: I don’t want to write static apps, or slightly dynamic html apps, otherwise I’d grab Rails (Which isn’t to say meteor isn’t a good choice for static content or the odd blob of content)

:smiley:

My 2 cents: Meteor’s #1 priority is simplicity/ease of use. React/AngularJS/Ember are almost the exact opposite of that as they are designed to be used by experienced Javascript developers that identify with problems like “scalability”, “performance”, “component-oriented architecture”, “complexity”, etc. It’s easy to mistake designing a system like templating for a large audience of users with designing it for your own needs.

Further, is it a good idea to phrase the situation as Spacebars/Blaze vs React? React is a flavor of the month framework; sure, there are good ideas in it, but there were good ideas in AngularJS too. Would this thread have been “deprecate Blaze in favour of AngularJS” 2 years ago? What about 2 years from now?

What’s the higher level discussion here?

For instance, how can Meteor take advantage of a longer term trend like Web Components (not Polymer/Material Design, but the actual W3C spec)?

12 Likes

Precisely my point. Right now you have to have some kind of mechanism to identify each template after a hot code push. That and the need for global variables to store data which is very much local. We should be able to do something like templateInstance.var(‘name’).get/set instead.

I’d say there isn’t strictly a single #1 priority but rather important tenants to try to stay close too. And I’ve already mentioned transpilers should exist (like spacebars/jade/etc). I have concerns about spacebars becoming more complex and looking less and less like regular html, specifically this topic spawn from nested expressions being added to spacebars, in that discussion, it came to attention that eventually javascript in templates would be possible (which could good thing, however I think that’s double edge, we pull closer to spaghetti code and nested expressions while really useful pulls again towards that). I think it shows that again, as much as we try things are coming full circle and we’re rounding ourselves back to a fully featured language so why not just shift priority and place javascript above spacebars as the target and have transpiler target those APIs.

I really don’t want phrase the situation as X vs Y, I want us to think about the best way to build user interfaces, I think react/JSX is an example, it has given us ideas, but it may not be the cure.

I think, there’s a couple smaller discussions happening from this topic. But, I think the most important notion is: how can we build the best user interfaces? The topic then proliferates into a number of questions/wants/needs like: designers want simple html, developers want javascript, are components the best approach, should we target web components (are they necessary).

Off topic again: I’m not convinced that’s such a issue, I mean, Session is now a reactive-dict, so if you want something to persist over a hot code push you can either isolate it with a reactive-dict or use Session, both migrate over hot code pushes.

Variables (reactive-vars) are ephemeral, dictionaries (reactive-dicts) are state.

I mean, I can see how it might be nice if you had the option to switch variables to be state/persisted but switching something from a ReactiveVar to a Session variable is not a huge painful undertaking

Having had careers using C# and Java, I have to agree with Serkan and Rahul. We’ve seen this progression of technology in other language and tech stacks. It’s actually not all that new. The isomoprhic APIs are. But componentization? Not so much. And from those other tech stacks we know that there are other (mostly human) factors to consider with regard to onboarding programmers, integrating the design cycle, etc. Isomorphic componentization is a big win; but it also comes at a high cost for existing code-bases, workflows, team structures, etc.

tl;dr - HTML and CSS may have 20 years of kludges and hacks baked into them (ug), but they’re used by a billion people. They’re obviously doing something right.

It would be great to see an HTML.parseJson() function, so that we could take the above example, and do something like the following:

    Template.__checkName("about");
    Template["about"] = new Template("Template.about", (function() {
      var view = this;

       // using the html2json library here
        var jsonFromHtml = {
          tag: 'div',
          class: 'content',
          child: [{
            tag: 'h2',
            text: 'Title'
          },{
            tag: 'some-other-element',
            attr: {
              class: ['other', 'foo'],
              someproperty: function() {
                return Spacebars.mustache(view.lookup("currentEmail"));
              }
            }
          }]
        };

      return HTML.parseJson(jsonFromHtml)
      );
    }));

If htmljs had a parseJson() function, I feel like I’d be a lot closer to being able to upgrade my existing apps towards React and Famo.us. That is, I’d know that my refactor path begins by refactoring my HTML files into JSON (which I could write a batch script for, or add to the starrynight utility more likely), and I’d know that JSON object works with Blaze. With that compilation point and refactor path done, it then becomes a question of writing React, Famo.us, and D3 methods to consume that JSON object and generate the necessary DOM trees in those UI layers.

With this kind of approach, I’d still be comfortable onramping junior developers, integrating designers and their design workflows, creating webcomponents using Blaze as per the W3C, and using most all of the latest/newest pure-javascript libraries. There would be one clear (and obvious) refactor path along a continuum towards pure javascript; and everything would fall nicely into place.

3 Likes

Very interesting, thanks for being so constructive.


Somewhat off-topic:

Grats to MDG for raising $20M!

The last paragraph burns my ears:

Right on Schmidt. :smile:

You’re missing the point. With reactive-dict you need a way to distinguish each template instance when the hot code push occurs. Instead of templateInstance.var("name").get/set you have to do something like reactiveDict.get/set("name_" + uniqueIdentifierForThisTemplateInstance) or new ReactiveDict("TemplateName_" + uniqueIdentifierForThisTemplateInstance).get/set("name").

A lot of times you have to go out of your way to provide a unique identifier for each template instance. And sometimes you can’t even provide such an id, as is the case when you’re writing packages.

This is a fundamental problem for migrating component state - at some point, you need to assign an ID to your component. Sometimes, this isn’t so bad - you can just use the _id of the relevant document, and the name of the component. Sometimes, you need to hardcode it and say “this is dialog #1”, “this is dialog #2”. React generates a unique ID for every component on the page every time, so even they haven’t solved this issue.

As far as template state, I find that many times when I’m trying to save something to template state that needs persisted, it’s much better saved as part of the amazing state manager that is the URL… This is not always the case but I would say that more often than not it is. It’s easy to get caught up in the single page app mind set and forget that we’re still working with web technologies that have some battle tested features.

Obviously things like form state don’t apply here.

Yes, I’m a strong proponent of using URLs for state when sensible.

Ah, I see.

We have records and the URL for state persistence. Could you elaborate with a use case for when those two mechanisms wouldn’t be sufficient?

I think in the JavaScript world you have to serve the flavor of the month or be left behind as Flash was. I also think you are severely over-valuing the W3C vs. Facebook. The W3C couldn’t do anything against Microsoft, and Facebook arguably is a threat to the Web itself. If Facebook is full-in on React and React Native the W3C is as likely the flavor of the month. You can enjoy your Web components along with your XSLT for Semantic Web.

As for ease of use, there will be visual builder tools for React components that are far easier than anything Atmosphere provides. And the output will run at production speed (including native) without loading spinners and flicker as Blaze tends to be stricken with. If Meteor can’t run the output of these tools good luck building as good ones for Blaze and getting people to take them seriously when there are 100x more and better React components.

Meteor has the full-stack isomorphic reactivity piece, and the rapid prototyping piece. It has “package” composition but lacks UI composition. React could glue onto it beautifully and realize the promise of instant web & mobile deployment that currently works in the Meteor demo but not much beyond that.

Asking here is going to get the opinions of people who fell in love with 2013 Meteor and don’t want its vision to adapt to 2015 much less 2017. You not only have to bet the farm you often have to burn it down and build a better one. Blaze was supposed to be the flavor of the month itself. That didn’t happen. Move forward.

3 Likes

I also think you are severely over-valuing the W3C vs. Facebook. The W3C couldn’t do anything against Microsoft, and Facebook arguably is a threat to the Web itself. […] You can enjoy your Web components along with your XSLT for Semantic Web.

Except that lots of companies, including Microsoft, Google and Facebook, are designing and support web components. So it’s a bit disingenuous to portray the W3C as somehow some niche organisation and adversarial to Facebook; the landscape today and the cooperation between browser vendors is very different than 15 years ago when “the W3C couldn’t do anything against Microsoft”. Everyone is working to push things forward in their own way and the W3C’s goal is to learn from the best of those efforts and compose them into new standards.

Asking here is going to get the opinions of people who fell in love with 2013 Meteor and don’t want its vision to adapt to 2015 much less 2017.

The conversation should not be about React vs Blaze. React will always work with Meteor, and that’s great. What the conversation should be about is, given that Meteor is designing a platform to make developing software radically easier, what should the templating layer (currently Spacebars/Blaze) look like? And in that sense, designing it based on what’s current in 2015 is not really relevant. That’s why I ended my last post with the question of what the higher level conversation here is; if it’s not MVC or JSX, then what is it?

3 Likes

Uh…browser? That’s definitely a 2013 thing. By 2014 mobile use had passed desktop and 86% of mobile use is in an app (typically Facebook) not the browser. A year later those numbers must be even worse for the hoary old W3C.

The browser in 2015 is used as a fallback for reaching legacy devices and Luddites and for shops that can’t afford cross-platform native app development. That latter problem Meteor hopes to solve, and React Native is exactly what Meteor needs to do that. If that means JSX, you do JSX. Stat.

If Meteor is the best solution to that problem, and includes easy support for the browser fallback as a nice-to-have, it lives. If it instead vaingloriously utterly conquers the problems of 2013, it’s merely a curiosity.

Now, that’s definitely not true. Many (typically B2B and scientific) applications require the presentation of huge (at least by small device standards) amounts of data - most often in tabular format. While there are ways of responsively presenting this on a mobile device, they fail in making is easy to comprehend what you’re looking at.

We’re developing a B2B app and adopting mobile first design (because you’re right - mobile access to the Internet is generally more significant in terms of volume than desktop). However, we’ve had to make some drastic design tradeoffs for the mobile view - and our own evidence suggests that few to none of our customers use our services over mobile.

For us, mobile is useful for notifications and top-level views of data, but the desktop remains as the most appropriate vehicle for our customers’ needs.

5 Likes

And a native desktop app would be far better than the desktop browser for that complexity level if you could afford to develop & maintain one, no?

Which is why I’m enthusiastic about eg Electron-Meteor apps. Desktop ergonomics with Meteor development. Nice.

A native desktop app is something you need to download and install. A browser is already there, especially when you switch computers. Updating native desktop apps is another story. Also Electron is not even close to being a native desktop technology. It is merely a shell to a web application.

1 Like

A native desktop app for IOS, another for Linux (one for each distro, because they all look and feel slightly different), another for Windows, another for AIX, another for HP-UX …

Native’s not always the right answer.

1 Like

You’re missing the very opportunity. Meteor does the hot code push better than the old web did. It does it now for HTML-based apps but that’s a legacy situation. Doing it for native apps—on all platforms—with full-stack reactivity, isomorphic code that runs everywhere thanks to JavaScript, rapid prototyping but with native performance & ergonomics thanks to eg React Native—that’s worth the $20M more MDG just sent the trucks to haul to the bank.

Throw the ball to the end zone the player’s running toward, not where they’re standing now. (I hope an American football reference isn’t lost on too many, sorry)

1 Like

I was referring to native desktop and I am yet to see one that is based on web technologies and is truly native. As I said, they merely are shells.

A user expects a native desktop app to be truly native in how it looks, how it behaves, how you interact with it. The controls to be the native desktop controls for the installed platform, be it gnome, kde, mac, win etc. Current web-tech based native solutions are nowhere near it. Heck, atom shell cannot even put the window close button on the left side where it belongs to on unity and that alone is confusing to everyday computer users.

1 Like