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.

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.

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.

Sounds pretty accurate. My perception is that a large part of the JS community has started to settle on React with Redux/MobX for state management.. Facebook also really lowered the barrier to entry for React with create-react-app. CSS is still up in the air a little bit, with many different solutions still being used. Sass, CSS-in-JS, CSS Modules+PostCSS and most lately styled-components (which is very promising, but lacks features like universal rendering out of the box).

I'd love to start pushing them to my clients, especially non-tech companies who can't afford to rewrite all their code every time a new framework becomes the fad, but I'm still kinda unconvinced. I'd love to read some real-world case studies.

At this point, I am likely to stick to React because of the support and community. But I could see myself using web components if it reaches critical mass.

edit: not usually one to complain about downvotes, but the document is literally what I described it to be. So, why?

Give a try to Vue.js, you can do exactly this. This framework reconciled me with frontend development after I discovered it on HN. Let's say you want to build a custom button with a special functionality and reuse it, like a button that logs when it has been clicked. Simply create a component like this (it's almost self-explanatory):

    <template>
        <div class="colored-box">
            <p @click="logClick">{{ text }}</p>
        </div>
    </template>

    <script>
    export default {
        name: 'LogButton',
        props: [
            'text'
        ],
        methods: {
            logClick: function () {
                console.log('The button "' + this.text + '" has been pressed"')
                this.$emit('click')
            }
        }
    }
    </script>

    <style scoped>
    .colored-box {
        background-color: red;
        border: solid 1px black;
    }
    </style>

Once your component is ready, you can use it in other files, and in a damn simple way:

    <LogButton text="Delete" @click="…" />

You seem to be building an argument based on the idea that there's "one true way" to write web applications. There isn't. People have very different ideas about what's best. While ostensibly different tools do the same job, they take quite different approaches. For example, take "gulp vs grunt vs make vs npm" for the build process. gulp uses "JS with a framework" for config. grunt uses json. make uses unix-y scripting. npm uses JS but plain node.js without a framework. Those are opinions, and there isn't a "right" one.

Suggesting there should be one tool for compiling web apps is a bit like suggesting there should be one C compiler for compiling C programmes. There can only really be one tool if there's only one way to do things, and that's simply not the case. With different approaches comes different tools.

But, all that said, it doesn't matter to an individual developer. Choose the tools that suit you, learn them, and be happy. Whatever approach you take to development is far less important than writing software that works for your users.

It doesn't help either that these js communities are splintered around every tiny issue and forked every other week (mean.js! is where I started the whole process). The feeling that there is zero permanence one week into a project does not inspire confidence either in my own project or the tools I have chosen.

I keep hoping the JavaScript community will have the same epiphany, but so far I'm still dreaming. Yes there are boilerplates that give you something working out-of-the-box, but still you need to keep up with which boilerplate is the latest and greatest. I'd argue Rails being so opinionated was one of the reasons for it's success.

[0] - https://www.quora.com/What-makes-Rails-a-framework-worth-lea...

That's what you get by shoehorning XML. Here's how you do it:

  var someThing = document.createElement("button");
  someThing.onclick = handleClick;

If it hurts, don't do that then - put all your build stuff and devDependencies in a separate module and install it into your next project like any other development dependency, adding new capabilities as you need them and bumping the version number when you need to like any other tool. You can start doing it yourself [1] or use one someone else made earlier [2] - there are an increasing number of these toolkits about.

> But seriously I can't use `<SomeThing onClick={this.handleClick}/>`?

You can do exactly that if you're using React or one of the many libraries which use React-like conventions (Preact, Inferno, Mithril.js etc.), so just use one of them.

> But why do I have to write a cryptic webpack.config.js for every project? Why do I have to install Babel and webpack separately? Why do I need to install 3 other babel related packages? Why do I need a .babelrc? It's just insane. There should just be one tool, one command. "modernjs build". Done.

You don't have to, and there are lots of tools which will take care of this for you (see [2] again). That's the exact same workflow I wanted, so I created it for the types of projects I'm working on [3] - it doesn't take much extra effort to turn your own preferred build setup into a command.

[1] https://github.com/insin/ad-hoc-reckons/blob/master/Creating...

[2] https://github.com/facebookincubator/create-react-app#altern...

[3] https://medium.com/@jbscript/quick-development-with-nwb-35f3...

"bundle install" in the command line.

That's my approach to dealing with frontend libraries but I tend to cheat by using Rails or RailsComposer to setup my project.