My previous job was on a product that used CoffeeScript and Backbone. As a stereotypical front end hipster, I was worried at first. I thought: "This is really old stuff in JS time. There are shiny new things out there". But I soon saw that while it would be more fun to use a new framework/language, the old ones are _totally fine_.
CoffeeScript was last updated a week ago. Backbone was updated several times last year and 1.4 is expected some time soon. There are online communities, there is documentation, there are answered questions on stackoverflow. Yeah, everything feels a bit old, but there won't be breaking changes to the API every few months and that blog post from 2015 that solves your exact problem is still useful!
Try looking at it like Angular is a language, not a framework. Sure, there are fancier ones coming out all the time, but that doesn't mean you have to switch every time that happens. The one you know has a bunch of apps built in it, you can still learn about its intricacies and there will be jobs for you for quite some time.
The code has got quite complex over time, and I strongly suspect I would have gone mad if I had used a different framework. I used to wonder why the hype over react, vue, angular etc.
The technology itself doesn't need to be new, exciting or practical. All you need is sufficient marketing $$$$$$ backing it.
I saw so much flawed frontend code which wasn't written by bad coders but by people which try to use always the fanciest and newest thing out there. Even if the docs written in marketing language claim otherwise, there's always a learning curve and it doesn't make any sense to switch the framework as soon as the learning curve getting flat.
It don't even use Angular's D.I. to test things. We don't have any tests in our app, what would you even test? It just displays data it gets from various sources.
But this:
angular.module('...')
.controller('BlahController', function(a, b, c) {
'ngInject';
...
});
var a = require('a');
var b = require('b');
var c = require('c');
exports.BlahController = function() {
...
}If you want to base your future on something you already know, you're in the wrong profession.
I met many people who bet on it, but most of them, even the 'fanboys' didn't seem to be 100% convinced of it.
"We panicked multiple times, bit it always turned out we were wrong and just didn't do things the Angular-Way"
Ember, for example, is kicking it for a much longer time, even with fewer ppl using it.
https://github.com/thewhitetulip/Tasks-vue
Vue.JS is great to use!
Even Cycle.js just has a few concepts and is even more flexible than React or Vue.
Angular 1&2 feels like someone let loose a Java or C# dev onto JavaScript, who tried to apply all the design patterns™
But I'm currently buying into the FP fad, haha
Also, I might have said it incorrectly, the thing is, Vue has a clean API, you have to hook up lifecycle functions, so all I have to write is a Vue element with six lifecycle functions and one function each for distinct AJAX call.
Sorry for the confusion.
HTML is content. CSS is style. Javascript is shit.
Polymer's got the BEST router system however. It makes the URL choppable at the component level, not the app level. So you can literally throw in an external component and it can add it's OWN part of the overall URL. I don't know any other framework that can let an external component eat some of the URL if it needs to.
But I guess React will be big for the next years, because of FB.
You just use pure javascript/web standards html to create your application. All the people that I worked with that used it were really happy with it.
The only client side JS library that doesn't seem to be a fad is jquery. Which now has backlash - maybe that's a sign of success in frontend dev land?
Current frameworks try to solve a higher level and most failed.
You realize React solves a performance problem that it imposes on itself, due to immutability, right?
Pre-react web apps to do attempt to re-render the entire page root on every press of a key. They simply handle events and remove/add/update the specific DOM nodes that are appropriate.
remember appendChild() and removeChild() ? These are quite fast.
That said, I like React's component structure... it works with me more than most. Though I tend to dev against react and build against preact-compat for reduced size. Which iirc uses real dom as point of truth.
The main take away from React is flux-like state management (ie Redux)... this is what helps with the real pain of larger apps (especially MVC) and that is cross-cutting concerns and state management. This is why Redux has been adopted, or roughly copied to all the up and coming options.
Yes, grids seem to always be a problem. This is one of those 'sticky wickets' (for frameworks too!). Of course it can be solved, but i'm more interested in the general case here.
>They simply handle events and remove/add/update the specific DOM nodes that are appropriate.
Don't bloody pretend you didn't.
I am specifically responding to this:
The "shadow DOM" at the root of React is quite central to its appeal, as it speeds up DOM changes by several orders of magnitude."
Of course you can take isolated sentences from me and purport alternate motivations (code clarity) to them so that you can make a new argument against that alternate motivation, but that is a different conversation.
The minimal transform is usually trivial to implement by hand:
var message = $('.widget__message'),
title = $('.widget__title'),
button = $('.widget__button');
button.on('click', () => {
$.get('/api/widget/1', response => {
title.text(response.text);
message.text(response.message);
});
});
I'm not saying this is a good thing, but I started to read more in the frameworks repos after trying a few of them.
I think this is a barrier for most devs, but I think it made me better at coding.
Seriously though, if there has to be a certain "way" of using some technology I can't help but remember Code Complete, that you should always code into a language as opposed to coding in it.
I did Ember while Angular was "a thing".
Angular-cli because it provides a scaffold for getting started with the project and getting something up and running. The documentation feels pretty good. I like the example app they are building and the documentation format (they provide the full source code for the files right there in the documentation, no need to navigate to somewhere else).
[1] https://github.com/angular/angular-cli [2] https://angular.io/docs/ts/latest/
The downside is for candidates looking to add a hot shot tech to their resume, Angular isn't all that sexy, but for anyone with JS knowledge willing to spend a couple of days getting up to speed with the app itself (the "tool stack" is minimal - npm, grunt, bower, browserify and since it's an existing app they are learning by example) - this is almost a no-brainer.