JohnMunsch

Any time the user interacts with the data on one line (among hundreds or thousands) calculations are redone at four different levels so we don't have to keep going back to the back-end to update the data, instead we can keep working with the data we already have.

So... With all that said, how did it work with Redux. Eh. Not so bad. I don't love it the way I loved AngularJS after I used it for the first time, but it's OK. The results are complicated but given how we're using it and what we're doing, I don't know how it wouldn't be complicated. I dislike that there's going to be a significant learning curve for anyone who encounters this page in the future, but the previous version of the page was a total trainwreck. At least this time I can do a lot of stuff and envision changes to the calculations and how it all updates and I don't break out in a sweat.

The biggest area I ran into problems was that a lot of the data we need to keep up-to-date is derived data (for example, an array of data for Angular UI Grid which has to use a heavily modified version of data in the state). Redux doesn't really do anything to help you update that as needed.

There are a lot of reasons there are so many plugins and add-ons for Redux, I think you might find it interesting to go over those so you can learn some of the themes they have and see what problems they try to solve. Actually, I think that's a worthwhile thing to do with any new technology. Go look at all the software which has sprung up to fill in the holes and you'll learn a lot.

I think it's fun to play with, but not ready for hard-core study yet.

* https://github.com/JohnMunsch/PaperQuik

* https://github.com/JohnMunsch/ClearAndDraw

They're both deployed on the web so you can play with them to see if they're in any way interesting to you. I wrote both of them last year to play with and learn some things and then I open sourced both of them.

Good luck with your learning.

For example, Vultr offers more memory and less hard drive space in their $5/month level.

These days I'm trying to get to a point where I have deployment software in place that would allow me to use Ubuntu LTS anywhere in a fairly short period of time. It's not that I'm actively looking to leave DigitalOcean, it's that I would like to be able to recommend something like Atlantic.Net's GO plan to somebody to put up a quick static site for $12 a year and know that it actually works because I've tried it myself.

But this is reality here: http://www.google.com/trends/explore#q=angularjs%2C%20ember....

See those lines hugging the bottom of the chart? They're everything that isn't AngularJS and React. React is clearly on the uptick and AngularJS on the downtick for the partial Feb data they've got, but everybody else is in the noise level.

Yet people here would have you think:

1: It's old! - Really? 1.0 shipped in mid 2012. In three years we will have gone from 1.0 to 1.4 and some work done on 2.0.

2: It's going to change tomorrow when 2.0 comes out. - Really? Have you spoken to the other guy just above? He seems to think it's decrepit, you're worried that anything you build with it will have to be thrown away tomorrow because of its astounding rate of change.

3: Using the Chinese menu system of putting together a front-end framework is perfectly viable. Just pick something from columns A/B/C/D and throw it together and start using it. You'll find lots of people who can answer your questions, there are books written on that particular combo of tech, and there are developers out there by the hundreds you can hire who will have no problem diving right into your projects.

No. It doesn't really work that way. Pick an arbitrary grab bag of stuff and maybe you'll make some excellent choices. But you'll have to live with that decision for quite a while. Even a less popular stack like Ember.js is going to get more third party support than whatever you decide upon for yourself.

Above all, please do a quick experiment for me. The next time somebody tells you that AngularJS is a dead end and you can't rely on it for years to come, ask them what they would have recommended back in 2013? Just two years ago. What set of stuff would they have advocated then that would be doing so well today and have this long lived future into 2017+ that wasn't AngularJS? Backbone.js? I don't know of anything.

My point is this, the front-end and JavaScript tech is changing at a rate way too high for anyone's predictions about two and three years down the road to have a lot of merit. AngularJS seems like a reasonable bet to have done well and have lots of info available about migration from 1.X to 2.0 so at the moment I'm still on that path. In the meantime I hope to learn more about Facebook's stuff to see if it gives me useful ideas or to see if I can incorporate parts of it into AngularJS (Flux seems interesting for instance and would likely slide into most of the frameworks). But the people below who speak with such certainty about the future... Maybe they don't see it as clearly as they think.

P.S. You can absolutely use anything you like other than the provided wrappers. If you do, just call $apply() afterward. That's the signal to AngularJS that you changed something that might require it to do updates elsewhere.

- In two years of doing AngularJS work as a full time job (plus weekend projects) I have never ended up digging through the source code. Nor have any of the people working for me on my team at work. So the idea that you have to do that is patently false.

- I'm not sure how much is there is to understand about the cycle. It happens whenever events fire which indicate changes might have occurred. Later, when browsers directly support watching variables for change, I'm guessing there will be no need for it anymore.

- Hmm. The templating thing is an interesting way of thinking about it. Yes, it is crippled in one sense because it doesn't have the full expressiveness of JavaScript. I can see that. On the other hand it's elegant because you don't have to drop out of your HTML to do your templating work somewhere else using a completely different syntax or location. I think there are really good arguments to be made on both sides of this argument.

- Fascinating. Almost all of my AngularJS code is JavaScript. The portions of the code devoted to keeping AngularJS happy are a very small portion of the total. Based on what I've seen of 2.0 controllers, services, etc. are simply standard JavaScript objects so it seems a hard argument to make that they aren't fully embracing JS.

- And the final argument is one of my favorites. I've seen it over and over again, "Don't use a framework at all! Cobble together your own thing out of best-of-breed pieces to make a system." That may work well for an individual (though I think it will not) but for a team?!? No way.

I'm not anti-React or anti-Ember, but I am anti-throw something together based on intuition and try to use it to build something real.

It works best on Chrome at the moment because it allows a true page image to go out on both Mac and Windows without any extra margins. Down the road I'm going to add more stuff to it like double sided pages, Cornell note-taking paper, the ability to customize lots of characteristics (like color of the lines and dots drawn), etc.

For the front-end I'd pick AngularJS personally. I used Backbone.js for a couple of years so I know what that world is like. Ember.js might be a good choice as well but it seems like AngularJS is going to swamp it due to popularity.

I wouldn't generate any pages in the back-end at all (the exception being a couple of one-off servlets if I have binary files or other things to download which are more easily generated in the back-end). All pages would be static HTML, CSS, and JavaScript and rendering would all happen on the front-end.

It's easy to work on, it's easy to figure out where bugs are (just look at the JSON flowing back and forth), and if you focus 100% of your security on that API and making sure that you never send anything you shouldn't to the front-end and that you validate everything the front-end sends to the back to the n-th degree, you'll never have security woes.

I have a variety of pens I like for different purposes. My favorite when I'm just dumping thoughts onto paper is my Visconti Rembrandt Eco Roller, but that's crazy expensive. I would very much recommend the Retro 51 Tornado Rollerball line of pens. They put down a big dark line with their regular refill and just glide across the page.

When I want precise lines there's the the Pilot Coleto line. They're like the four color Bic pens you can switch between colors with just a click but the refills aren't Bic garbage, they're Pilot Hi-Tec-C line of refills, dozens of colors are available, and they come in 0.4 and 0.3mm sizes so you get a thin line for design or doodling.

I'm not sure about the quantity picker though, what's that going to look like in the HTML? One element in the code gives you all of the quantity fields?

My use of directives to date has been rather limited so I look forward to exploring that more in some upcoming work.

I had meant to do the same with Ember.js as well but AngularJS did the job so well that I decided to just go with it. So possibly Ember.js is even better. I don't know. But I can say we haven't really regretted AngularJS yet.

As for Backbone.js by itself... It's OK, I liked it but we had a large project with as many has half a dozen people working on it at its peak and the problem we got into was all of the huge gaps in Backbone.js that you typically fill with other software (two-way binding, validation, templating, AMD, etc.) and if you don't figure out your solutions for all of those gaps before you start every developer in the group ends up filling it his or her own way. Especially if you're under a time crunch and writing really fast.

We ended up with a working project at the end and it was way faster than their old solution but it was a chimera. Every part of it appeared to be a different animal. With AngularJS a lot more of those parts are part of the framework itself and there's less room for that kind of problem. I'm using it for large project work now and liking it a great deal more.

I still want Chrome, Firefox, and MongoDB stickers too. Feel free to send me some :)

Backbone.js by itself is just missing so many pieces that the name is a real misnomer. I don't know anybody who could stand up if their real backbone was missing that many vertebrae.

Based on their manual they use a separate server and everyone hooks a native app to that. So they effectively went with option two.