Angular, React, and Blaze

announce
62

I want to believe!

But it’s kinda hard to believe that they are “nailing all the things that React NPM ecosystem is nailing before them”. I’d really like to see proof of this before I spend any more of my time on it. I’ve already spent a few hours researching the state of the clojurescript and Om community and it really doesn’t seem as “big” as you’re portraying it.

They don’t even have a landing page! For something to get the kind of traction that React is getting, you really do need a full-on marketing effort. Unfortunately, I’m not seeing that effort for clojurescript and Om. That being said, I watched the David Nolen talk posted by @dinos and I absolutely love a lot of their ideas. I genuinely believe that it probably resembles what we will be using in the future, some day.

But to suggest clojurescript to this crowd? I’m all for optimism, but it’s really unlikely. React itself took like two years for it to get popular, and a lot of that was not only from Facebook’s marketing, but also thanks to the “fall” of Angular (including the Angular 2 drama).

I’d love to get involved in the Om community, but I would really like to see more “proof” of it gaining traction. Thanks for pointing it out though, I had a fun day learning a tiny bit about Om and Om Next.

2 Likes
63

Could we possibly get some specifics on what work you’ll be carrying out in regards to Angular, React and Blaze? Like specific work not just vagueness? I think it’s fair that people should be able to know your intentions and make a decision as to whether Meteor will be viable for their view layer of choice. Right now I’m not convinced much is going to be done on React for example and I don’t want to go back to a dead end view layer like Blaze.

2 Likes
64

I think supporting the current Blaze for the near future makes totally sense, because many apps have started with Blaze and can now transition to React. That’s something, you don’t need to do all at once, because you can use Blaze and React at the same time. The same is true for AngularJS.

I don’t expect any improvements to Blaze, because most of the ones I want to see are breaking API changes. And React does it already in the way, I would like to see it in Blaze. So I just use React for new UI components.

It’s great that the Meteor Guide outlines a way to build Blaze components that uses many great ideas that I have first seen from React. I think they make building, maintaining and understanding of larger apps easier. This also gives you a smoother transition to React, because you can use exactly the same ideas there.

I also like the encouragement to add support for React and AngularJS for full-stack packages. I personally only use useraccounts, but this package is very valuable to my app.

65

You do the math. Relay style features is the standard way of doing things in Om before React and it does a lot more, i.e. the stuff I already mentioned.

They are using Github pretty much exclusively. Om has been around for 2 years, almost as long as React. I felt the same way about FP stuff for a while–“it cant be all that, if we [as a community] haven’t switched to it from OOP yet.” But the reality is a very psychological thing: we all have been having the mindset you have (basically fear of the unknown, and not wanting to spend more time we hardly have to learn new things), and therefore some great technologies have been held back unnecessarily. It really boils down to that sorta stuff.

Om had Time Travel since 2013: http://swannodette.github.io/2013/12/31/time-travel

Elm since September 2014:
http://elm-lang.org/blog/time-travel-made-easy

These are features that just became prevalent in the JS/React world in July 2015!

So again, you do the math, the JS community is copying the best stuff from their functional counterparts. The latest “higher order component” stuff is directly a functional concept that you use day in and day out in ClojureScript and Elm.

So you have a case where these technologies are totally useable, but aren’t being used anywhere near enough in proportion to the value they bring because we have mental blocks holding us back, not because the technologies aren’t ready for us.

When you label “this crowd” as slow and behind the times essentially, my perspective is you are holding people back. My perspective is right now more than ever u gotta push yourself to stay ahead of the pack or get lost behind. The greater react/NPM community is considering all this. If u look at the upcoming facebook react conference schedule, the precise technologies they consider besides react to be important and and have talks are: Om next (clojurescript), cycle.js, and Elm.

Meteor has kept us in the dark, whether we wanna realize it or not. There’s nothing I can say except you are going to miss out if you want to maintain your current mindset. This stuff is mature enough, even if ur only way of judging it is whether om next has a landing page or not. Elm is used in production by several companies by the way and Elm is considered the most forward thinking tech of all of these.

Perhaps more importantly, it’s not about any specific technology–it’s about what they have to teach you, what techniques you can learn from them. React is borrowing right and left from not just functional programming, but these specific technologies! Elm, ClojureScript/Om, Cycle/Observables. Programmers day in and day out are writing better code because they are learning from these technologies. They may be writing React code or Blaze code or even backend code. Meteor keeps us locked in a “one technology to solve all our problems” mindset. It’s great to have such a full-featured option (and the reason I’ve used Meteor for so long just like you). But to write better code (and write it faster), your mindset must be more expansive.

  • Immutable functional programming makes testing and therefore maintainability many times easier.
  • Time varying values (i.e. “Observables” and “Signals” as they are called in Elm) reduce code that you used to take many procedural steps down to declarative mathematical definitions/equations
  • functional composition, transducers, etc, allow for your code to be “lazy” and therefore save compute resources–that means you can design an algorithm by combining functions and then run your data through it at the end. This is as opposed to what you would do with underscore where you map, then filter, then reduce etc, each time creating a new stack frame with all the same variables in memory.
  • “Observables all the way down” means you can circumvent stateful bottlenecks at every layer of the stack. You know how you can switch out your webservers in your cluster, but the database is far from as easy?? Well ClojureScript’s datomic database provides this. Watch the “Turning the Database Inside Out” video. There’s really a lot of value you can get here–from time traveling the entire database (not just a client side store) to subscriptions/livequery without hacks.
  • and there’s a lot more…

That all said, I’m an OOP advocate. I spent an entire year up until November building an OOP framework on top of Meteor. Everything is a class/object. Every file you open is a class. So I’m not just a ship-jumper without grounds. I’ve researched all this, and even though these FP languages are bit harder to read, it’s the “one true way” of the future. CLJS lets you use OOP-like syntax if you want–and that’s exactly how they approach React components in OM. I’m the first one to say that representing code as objects with methods etc more closely mirrors human experience. And OOP will continue to beat FP on that front. But the immutable functional “observables all the way down” stuff just trumps that. I imagine as I get deeper into FP it will feel just as natural as OOP to me.

So I don’t know what else to say here except all my research points to this stuff being plain out BETTER and not IMMATURE. Clojure is a hosted language–it uses Java on the server. That means you get the benefit of the entire Java ecosystem to securely/etc launch your app. You can interface with Java from Clojure and you can interface with Javascript from ClojureScript. So client code lets you make use of the js ecosystem. There’s very little difference between Clojure and ClojureScript by the way–for all intents and purposes they are the same language. You can launch full stack apps just as you do with the meteor command for the most part. …So anyway, my point in this paragraph was because these languages are “hosted” they are less immature than they might be otherwise.

I’m done for now, just don’t be afraid my friend. Find the time. We’ve all been there, and if there ever was a time where it might be worth it to take the leap on emerging technologies, now’s it. If this stuff is leading the “Cambrian explosion” in the javascript world, it may be worth checking out. It’s gonna be different this time. With things like “WebAssembly” it very soon will matter what language you’re using to target clients that support javascript. That’s basically the underlying theme here.

5 Likes
66

Thanks @sashko, amazing!

Any chance you could have the Cordova code in JS so it’s cross platform (so we can support other platforms besides iOS and Android). In fact, you can probably reuse (almost) all of your current client DDP code.

If you guys need help, we have enough experience and can be available to brainstorm.

67

The current version has all of the hot code push written in JS, and that was one of the things that made it unstable. I think @martijnwalraven is intentionally rewriting it in native code to improve the stability and performance. Perhaps we could collaborate on other platforms somehow, or have the old js code as a fallback for other platforms?

1 Like
68

Since you guys are rewriting this I think you can drop in a super dope feature: a progress report of the hot code push download. Right now it’s a bit of a mystery but it would be great if we can get a value to show something like ‘your update is 60% downloaded’

The killer UX here is to notify the user of the impending download, show the download progress in case they are excited and want to wait for it, then prompt them to reload the app.

Cc: @martijnwalraven

5 Likes
69

You mislabel me. I’ve been a Haskell/Lisp proponent for years, I am well-acquainted with FP and its community (but not clojurescript). My point is, it’s not reasonable (nor helpful) to expect people who have to deliver client projects in a matter of weeks to be able to take out a significant amount of time to go learn ALL the things. A lot of FP proponents go on long tirades about why the masses need to “wake up” but the general public end up resenting them instead, and that’s the issue with a lot of people in the FP world.

If you haven’t already, read Letter to a Young Haskell Enthusiast. The key to converting people to FP is not to ram it down their throats, but to recognize their specific business needs and cater to it as best we can.

It takes time, and I think the sooner we recognize that instead of rushing people, it might actually get more momentum. In any case, this is digressing from the main topic, so I would suggest we take this conversation elsewhere.

2 Likes
70

I think my particular story is important, given I’ve used Meteor exclusively for 3.5 years–been in love with Meteor etc–and just recently spent the time to dissect FP. Because of that I think my particular findings are very valuable to the Meteor community.

This is as opposed to someone that has jumped from technology to technology over the years as a “tinkerer” and is now fanatical about FP with no real foundation having ever had to build and stick with a production app in a now dated technology. Or perhaps compared to simply someone from the greater React world that has minimal Meteor experience. I EAT SLEEP AND BREATHE METEOR! And as that person, my perspective is it is helpful to share my experience and my perspective that it is super important to checkout all the stuff going on with FP. There’s 3 specific technologies to check out besides react: ClojureScript/Om Next, Cycle.js, Elm. There’s a very specific trajectory of study one must follow to be current with the times, not just a smorgasbord of whatever a crazed tinkerer pulls out of a hat. I don’t “expect” anything from anyone. I know first hand how hard it is to devote this time, and specifically to the current FP craze (not just learning any new technology). That’s why I’m trying to impart as much as I can so others dont have to expend the time I did. There’s no “Tirade” here–just if you’re considering React and you’re about to expand your mind past Blaze, and if you don’t wanna waste your time on a technology that may end up being a stepping stone or trick yourself into thinking you’ve done all the leveling up you’ll need for a while, make sure you give the functional pillars/technologies that are influencing React as deep of an analysis your time can afford.

7 Likes
71

I think the React and Angular have sufficient support with teams of them. So Meteor should focus on Blaze mainly. Meteor had his fame a time ago, but now this fame is in React. And about the future? I think that Meteor is more prepared for the future, using pure Javascript and following HTML rules and the way the JS, CSS, HTML should be.
I think that a great work in Blaze 2, can return his fame.
I will be waiting for the good news…

72

Cc: @martijnwalraven

I can see where the stability and performance can be issues. However, iOS has introduced a new webview type (wkWebView I believe) which allegedly has much better performance, and on Android, we use crosswalk (i.e. include Chromium browser into the app for consistent performance across Android devices). Won’t these make life easier with pure-JS?

For desktop, we were thinking of using one of nw.js / atom / electrify as a dummy browser that opens the web app. A basic client-side script can also be called to do native desktop activities (e.g. fullscreen, onFocusOut etc.)

73

One of the reasons for the upgrade is precisely to support WKWebView. In order to do so, we need to run a true local web server to serve the web app from (because the old plugin uses NSURLProtocol, which is no longer supported). The web server itself has to run in native code, and in the rewrite we’ve also moved the file transfers to native. The old mechanism wasn’t pure JS either, but used the Cordova file transfer plugin to download individual files, and that lead to some serious stability issues. Moving the file transfers to native code in our own plugin has allowed us to make the hot code push process much more efficient and reliable.

8 Likes
74

Some of the best news I’ve heard this year

1 Like
75

Please get us some feedback value for how far along the update download is :innocent: also, one thing I never understood is if closing the app causes the download to reset. Would be great if it would not since over the air downloads are tough especially in developing counties

76

I’m giving a talk about the Cordova updates coming with 1.3 at the next Meteor Night/DevShop on January 21. The plan is to have a beta out before then (probably only for iOS though).

With the new plugin, downloads will no longer start over after closing the app and will always reuse files already downloaded. Only downloading changed assets will also help considerably.

7 Likes
77

Nice, for some reason I wrote incremental updating, which sounds like the new feature… Super cool, looking forward to it.

78

A roadmap would be a huge benefit.

2 Likes
79

Actually, following the community, I think the fast, fast majority would like to see Blaze with a strong future and MDG with a clear roadmap. All the React,Angular, Aurelia, and so on would be non-core additions.

2 Likes
80

One more I think much desired feature would be the ability to run Cordova plug-ins locally. If that can somehow make it, that would be great.

81

Can you elaborate on what you mean by ‘running Cordova plug-ins locally’?