In recent years we've seen an emergence of tools, each of which require practical experience and often have a steep learning curve. In this new world of enterprise frontend development, one can easily get lost.
So, sometimes it's helpful to have a reference what's currently in use to reduce the search space. The scope of this document aims to be such a list based on the biased perspective of a developer working in the banking sector in continental Europe.
All these tools have been used by teams I worked with in several enterprise-scale projects with tens of thousand active users. As always, for projects of smaller scale you can and should get much more experimental to broaden your mind.
It may seem odd to start an article about frontend development with a backend section but the interface, often a RESTful API, is just as important for the frontend as it is for the backend. Ideally, a frontend developer should design the API either together with a backend developer or on his own.
Golang is an interesting case since I wouldn't recommended it without a "but" immediately coming afterwards. It became immensely popular in the last few months and great tools have been written in it, e.g. Docker. The language itself is opinionated and you can't shake the feeling that something is missing, although every Go enthusiast would deny that anyone would ever need generics.
However, it provides great asynchronous lower-level primitives and works really well with the modern web development paradigm, especially if you use a microservice architecture.
I suggest to use it on a small scale first. Try to write a few utility programs and evaluate how it fits in your big picture.
Let's face it, most enterprise developers are versed in Java and there are very interesting web frameworks which have a promising attitude which are not really "there" yet in terms of maturity.
Spring was generally considered a heavyweight framework and alternative to an ancient Java EE setup. Itself plagued with XML configuration, it was boosted to a new dimension by this build tool. Spring Boot throws out the ugly XML and gives you a really good way to write the RESTful services for your frontend.
Java EE started as abomination and has become a patchwork with community-driven inspiration. As time goes by the updates become better and better. The JSRs and their intentions are good but don't go far enough, it always feels like a compromise between the previous bloat and the new shiny.
The Gradle of JavaScript build tools. You code a lot of micro-tasks and plug them like Lego in a pipeline. Every task is valid NodeJS code which has the advantage of being fast. However, you can expect a bit of learning curve here and sometimes you encounter plugins with unexplainable behavior.
Overall, it's not as mature as Grunt but very fast growing. Nevertheless, in large projects it always feels like a pain to invest that much time in the build cycle.
The Maven of JavaScript build tools. It has a larger community and often the plugins seem to be more hardened. It can become quite confusing to handle the configuration monoliths. People who have worked with Ant or Maven will feel less estranged by Grunt as compared to Gulp.
I could have written "Flatty Design" instead of Material Design since its implementation is not production ready. However, the concept behind Material Design is the amalgamation of design knowledge and whatever happens to the brand, the concept won't vanish fast.
The business world equates Bootstrap with responsiveness and no other framework is even mentioned. Either you are expected to roll your own solution or use Bootstrap.
It seems to be strongly tied to the fate of Bootstrap - although there really is no need to use Less instead of Sass. However, it continues to be the go to preprocessor. In terms of innovation I would like it seen to be replaced by Sass/Compass.
Node is an interesting tool if you use it extensively, e.g. for using it as build alternative. It is quite established but seems to have some underlying issues which io.js is trying to solve.
In a large project with lots of custom modules there are some issues with Git and Semver that require hard thinking and cautious acting. It is advisable to use an own registry at this point to mitigate some of the issues.
"Why does one even need Bower?" is a valid question. Unfortunately, dependency management by npm alone just doesn't cut it for frontend dependencies in production. Bower provides a flat dependency structure opposed to npm's infinite recursive module approach. If you pair npm and Browserify you get a much better experience and could eliminate another tool.
If you don't want or need to use Browserify, you should use Bower instead and don't think too hard about it.
One of the best Java IDEs has been extended with frontend capabilities and got a little brother called WebStorm which works great as well. Basically, it has everything out-of-the-box and no complicated setup is required. You install it and everything just works perfectly. Unfortunately, you pay with speed.
Sublime is the most popular editor and it's basically ingrained in our muscle-memory. Many people thought it was dead after the long drought of updates but recently there have been new develop builds, so you shouldn't count it out.
So far it survived everything thrown at it with its primary strength of being fast. Atom is a contender which isn't dead yet but will probably never surpass it in means of speed.
Likely, I'm not the only one who invested dozens of hours in customizing my settings and clashing plugins. A dreadful thought if I would need to start anew. And still, there are parts which are an extreme pain to customize and sometimes it's completely impossible.
React is the new prodigy and can't do anything wrong right now. Especially, paired with the Flux architecture it's a real game changer and virtual DOMs are here to stay.
It gives you a certain degree of freedom since it cares only about the view and is lightning fast. However, I feel it's not the end of all our issues and could be optimized much more.
Also, React Native.
We were shocked by the radical approach which Angular 2.0 may take but after the dust settled, we thought that it's the right choice considering its age and upcoming ECMAScript changes.
Nevertheless, we still use Angular 1 actively in new projects and consider to use it for a few years. The gains in terms of development speed and maintainability are much preferable compared to native JavaScript.
Also the name is established and it's in the heads of our management, so no matter how different the next Angular version will be for developers, it will still be a factor to consider.
ESLint does the same as JSLint and JSHint but exposes an abstract syntax tree. This allows us to write our own rules whether it be styling conventions or just possible error patterns. Plus the code is by far better than JSHint's and the documentation is incredible.
JSHint just checks for problematic patterns and doesn't enforce conventions like JSLint. In reality however you want to enforce conventional rules in projects. Also it doesn't provide pluggable linting rules and extending a base configuration feels dirty.
Certainly the better module loader when compared to RequireJS but also not the silver bullet. However, it gets quite interesting if you are Node/npm-heavy anyway. Webpack is lingering right behind it and definitely worth a try until ES6 will be common.
Working with frameworks like AngularJS we noticed that migrating to AMD syntax is a real chore and its style interferes too much with the way we program in these frameworks. The benefits would have been too small to invest the required effort.
Easy to set up, Mocha covers everything you want from a test framework plus you can plug-in nearly every assertion library if you want to. Especially, useful when doing asynchronous tests. However, the error messages in such tests can be extremely hard to debug.
Awful when it comes to asynchronous tests and adds lots of bloat. Not recommendable if you do TDD.
It shouldn't matter which editor a team member uses and therefore we need a common ground which EditorConfig enforces. It is a plain configuration file and every editor, which I've used so far, supports it.
Pull requests, cherry picks, stashing and much more makes Git the absolute must in a serious project. There is no hardened alternative. I would even go so far and say that there should be no enterprise project out there using any other SCM.
Maybe your IDE integrates Emmet as plugin or you installed it separately, no matter which way, it is so helpful if you write larger portions of HTML. I'm still shocked that some people still write the entire markup by hand.
Lo-Dash 3 is the new functional black. It started as a fork of the Library-Who-Must-Not-Be-Named and since then has surpassed it's grandfather. Extra functionality, 100% coverage, better usability, better performance. There is no reason not to use it if you want lean code. It's also the reference for best practices in JavaScript programming and module design.
Previously known as the savior of functional JavaScript, has become an example of how not to handle issues. Hidden breaking changes, disabled tests in order to push a new version and sentimental versioning.
This type of architecture mirrors the current changes in software engineering and is hard to define objectively. It embraces the new paradigm of continuous integration and delivery and it's very suited for the rising devops mentality. In regards of development it promotes small, cross-functional teams.
Being consistent is one of the virtues of a programmer and this also counts when designing APIs. The HAL specification provides a reasonable approach to design RESTful APIs in a explorative way.
Test-driven development was a fanatic religion which finally went extinct. From the ashes rose a more practical approach to testing which actually allows you to reflect on the tests you do. Whether you write unit tests or API tests or E2E tests first or in parallel is up to you but there is no argument for not writing tests at all, they just have to make sense.
"Any organization that designs a system (defined more broadly here than just information systems) will inevitably produce a design whose structure is a copy of the organization's communication structure."
This last item on the list is a cumulation of everything mentioned before. Every tool, language, framework and methodology rises from the principle that we need new structures within the companies itself, starting with your colleagues, your team, project management and finally even management itself.
If you can't communicate in a meaningful way with each other, everything will be hard, slow and aggravating. If you do not nourish an open communication, you shouldn't use any of the tools mentioned here because they will fail to help you no matter how hard you try.
One symptom of this disease is the separation of teams and sometimes bad blood between them. There should be no communication barriers between frontend and backend for example. You should know what they do, what blockers they have and vice versa. They should be as accessible to you as you should be to them.