I'm a backend developer (Java/Kotlin mostly) but I also spend a lot of time dealing with other people's frontend code as well. I'd recommend not being too dogmatic and look at requirements and also look forward a bit to 1, 2, and 5 years down the line. My main message is: things are changing and a lot of stuff that seems right now may seem backwards not to long from now. This is more true on the frontend than on the backend.
The vibe I'm picking up lately is that react + typescript is not completely horrible for frontend development and my impression is that I can hire people to work on such projects. Nothing wrong with this stack. A solid conservative choice. But what about five years from now?
Some trends that I'm picking up lately that could start changing web stacks in the next five years and should be kept in mind when choosing stacks right now:
- Statically compiled languages are now a thing on the frontend. Most of the senior frontend people I know are very opinionated about which transpilers and tools they use but writing "native" javascript seems much less of a thing then it used to be. E.g. Typescript seems popular now. Just a few years ago I would have seen a lot of people pull up their noses for e.g. coffeescript but typescript seems to have broken through that. Probably for a new project, you should go statically compiled from day one across your entire stack from day one.
- WASM and PWAs mean that most current javascript frameworks will not be the only game in town for developing complex UIs in browsers. I'm seeing a lot of activity around Kotlin and Rust lately and they are looking to provide full end to end solutions that effectively replace large parts of the stacks that were common in the last decade or so across web, desktop and mobile development. People seem to dislike things like Electron, yet it clearly fills a need. WASM and PWAs take that to the next level.
- This also means that fullstack no longer means node.js and browsers: other languages are now becoming full stack. For example, Rust is a proper full stack language and you can do anything from OS kernels to browser apps in it. Likewise, Kotlin can compile to the jvm, javascript, wasm, and native code. C# and a few other languages are also moving into browsers. This means javascript or transpiled javascript are not going to be the only way to do full stack in the next few years. This also means that new frameworks more appropriate to these languages will start competing with e.g. React. I recommend keeping an eye on this space but being conservative in rushing in as a lot of this stuff is changing rapidly.
- VS Code seems to slowly bring frontend work out of the stone age where it has been stuck since the decline of the likes of Visual Basic, Delphi, and other IDEs for UI work in the late nineties. Code completion, real time feedback about syntax issues, and even some refactoring support are now possible. It's still horribly primitive to what I'm used to for backend development. But things have improved a lot since VS Code came out. Using editors that don't tell you your code is broken still seems to be a bit of a macho thing. But these days there is much less excuse for committing code that demonstrably is syntactically incorrect, has unused/redundant code, imports, etc. Or includes things that obviously won't work as intended. Whatever you pick, make sure there is awesome tool and IDE support for it.
The vibe I'm picking up lately is that react + typescript is not completely horrible for frontend development and my impression is that I can hire people to work on such projects. Nothing wrong with this stack. A solid conservative choice. But what about five years from now?
Some trends that I'm picking up lately that could start changing web stacks in the next five years and should be kept in mind when choosing stacks right now:
- Statically compiled languages are now a thing on the frontend. Most of the senior frontend people I know are very opinionated about which transpilers and tools they use but writing "native" javascript seems much less of a thing then it used to be. E.g. Typescript seems popular now. Just a few years ago I would have seen a lot of people pull up their noses for e.g. coffeescript but typescript seems to have broken through that. Probably for a new project, you should go statically compiled from day one across your entire stack from day one.
- WASM and PWAs mean that most current javascript frameworks will not be the only game in town for developing complex UIs in browsers. I'm seeing a lot of activity around Kotlin and Rust lately and they are looking to provide full end to end solutions that effectively replace large parts of the stacks that were common in the last decade or so across web, desktop and mobile development. People seem to dislike things like Electron, yet it clearly fills a need. WASM and PWAs take that to the next level.
- This also means that fullstack no longer means node.js and browsers: other languages are now becoming full stack. For example, Rust is a proper full stack language and you can do anything from OS kernels to browser apps in it. Likewise, Kotlin can compile to the jvm, javascript, wasm, and native code. C# and a few other languages are also moving into browsers. This means javascript or transpiled javascript are not going to be the only way to do full stack in the next few years. This also means that new frameworks more appropriate to these languages will start competing with e.g. React. I recommend keeping an eye on this space but being conservative in rushing in as a lot of this stuff is changing rapidly.
- VS Code seems to slowly bring frontend work out of the stone age where it has been stuck since the decline of the likes of Visual Basic, Delphi, and other IDEs for UI work in the late nineties. Code completion, real time feedback about syntax issues, and even some refactoring support are now possible. It's still horribly primitive to what I'm used to for backend development. But things have improved a lot since VS Code came out. Using editors that don't tell you your code is broken still seems to be a bit of a macho thing. But these days there is much less excuse for committing code that demonstrably is syntactically incorrect, has unused/redundant code, imports, etc. Or includes things that obviously won't work as intended. Whatever you pick, make sure there is awesome tool and IDE support for it.