If we consider the field of web development, or development with web technologies (for example Electron apps), how long does a person need to be "out of the game" to become uncompetitive?
In other words, if I'm building an Electron app I'd prefer a solid engineer who has never written a line of Typescript to someone who only knows Electron.
I agree with you on this.
The reason why I am interested in this, is that in my opinion engineers must always be open to learn new things and new tech. So, I was wondering, if it is possible to make the argument "If you stop learning or at least following the industry for X months, you are out of the game."
I'm just gathering objective opinions to to able to argue that continous learning is an important skill for engineers to begin with. As in, you can't just finish Uni knowing intermediary programming in Java (for example) and be content with it.
The former doesn't necessarily guarantee the latter. I'm gonna answer with the path less traveled in this thread with regards to your question. When you mention competitiveness, do you actually mean in terms of the job market? If so, unfortunately most people that are your first eyes to your resume when you hit that submit button are not as technically inclined as a programmer. Which is why it's often better to directly reach out to a team lead of the programmer department. Fundamental concepts don't work with 3rd party recruiters either, as most of them are not very language agnostic when it comes to matching you with job opportunities. The exception is with the largest of companies. They'll value fundamental skills more highly because they can absorb the risk of hiring someone to ramp them up with their work environment. Most medium to smaller companies can't afford much ramp up time. From my experience they want you to hit the ground running (seems to be a popular phrase with them) in whatever web framework they use.
So for your benefit, you will look more appealing to hire by applying to larger companies. Smaller companies tend to interview more in concrete framework trivia while the large ones tend to test you on algorithms and other language agnostic concepts.
I mean competitive in a broader sense. I.e. do your tech skills make your business more competitive?
Electron is an interesting example. If you are smart, you can use it to deploy your application to desktop, as well as the web. Meaning you don't have to have 4 separate teams for Windows, Mac, Linux, Web. Being productive with Electron is therefore a competitive skill in my opinion.
I often have to argue with older engineers. There are a lot of prejudice against current technologies, like for example Node: "JavaScript is a dumb language", "it's not real programming", etc. I am exagerating, of course, but the attitudes are still there. So I am trying to build a compelling case for learning and developing.
Learning a new stack is extremely important for an engineer because it exposes you to a lot of new problems. Things you've never heard of, unless you already got your hands dirty. I'm talking about reading poor API documentations doing reverse engineering work, understanding how to implement a concept and the large gaps between paper and code, how to pick up the right tools for your needs which will save you time and money moving forward, how to integrate, etc. Integration is about %70 of our work today. If you haven't used at least 2 different stacks in your life, you ain't know about integration problems.
So, yes, engineering is a lot more than a set of concepts. I would value someone who jumped into a bunch of different stacks rather than a google-like engineer who doesn't even know how to right HTML (which is a real joke between ex-googlers, we say we didn't even know how to write an HTML page when we left google).
I'm a front-end developer.
I learned the CSS box model and how to write HTML once and use this knowledge for over 10 years now. CSS got a few new selectors since then, but the core stayed the same. Just this month I had to learn Flexbox for React-Native purposes, which felt like learning a whole new CSS, but other than that not much changed.
2011 I learned JavaScript in depth, with all the books, Pro JavaScript Techniques, JavaScript: The Good Parts, etc. Till ES2015 I didn't have to learn much new and all of that is still valid knowledge, I just don't use some of it anymore, because better ES2015 alternatives.
Some people say, there are new frameworks every month and I can't argue much with that. On the other hand, no one forces you to use a new framework every now and then. I used ExtJS, Ember and React in production. I could have learned on of them and used them till now. They're all still maintained and updated. Went away from ExtJS to Ember, because Ember is free and ExtJS rather expensive. Ember didn't have as much out-of-the box as ExtJS, but the stuff made with Ember felt "more web" to me. Also some of the concepts were easier than in ExtJS. Then I switched from Ember to React, because it had even less concepts that were also easier than Ember. Also React seemed to be much more than a simple "web framework" because of things like React-Native or ReactXP.
I almost scored a ExtJS project this year and the lead dev said, I could use most of my ExtJS4 skills, I acquired 2011, in the current version of ExtJS.
So...
Is Web development changing fast? Probably.
Is it changing fundamentally? Probably not.
As far as technology stacks go:
* Some domains change faster than others. E.g. front end web dev has rapid change, with new JavaScript frameworks coming out every 6 months. Back end web dev is much more stable.
* Even when change happens, it mostly affects new projects. For example, while C++14 may be fundamentally different, most C++ projects were started years ago. Project I worked on back in 2004-2005 was started in 2000 and is still going strong. So while it's modernized somewhat as the language and compilers and libraries changed, I'm sure it's not at bleeding edge in terms of features.
Thus there are many many places you can work that aren't using the newest/trendiest technology.
Practical advice that results from this:
1. Focusing on fundamental skills that transcend particular technology is more useful than specific technical skills in the long run. (E.g. learning big picture thinking: https://codewithoutrules.com/2016/08/25/the-01x-programmer/).
2. It's good to change projects or companies every once in a while, existing projects are always on older technologies and you get out of touch with latest tech.
3. It's good to keep an eye out on new technologies so you know they exist and can use them when necessary. Doesn't require being an expert or even learning how to use them, just being aware they exist and what they're good for. Since many new technologies are gone after a year this also means you don't overinvest in something - you only pick it up if it's actually useful for the job at hand. (More at https://codewithoutrules.com/2016/10/07/growing-your-toolbox...).
E.g. low contrast and flat UIs are both fashionable and terrible.
I would be implementing a design done by a designer.
Your hallmark would miss me greatly.
I rarely use any design-related toolkits you would be able to see from the front end (bootstrap? etc), either.
It not necessary to keep writing stuff following trends you just have to follow updates, newsletters, articles, so you dont struggle when you reenter the market.
"1year or more out there are entirly new stacks, new libraries, new versions, new ways of building things etc."
You think there are any dev teams which change their entire stack every year? As for new libraries, thats what documentation is for, nobody gets hired because they have a the newest & hottest libraries APIs memorized.
Being a good developer has very little to do with knowing all of the trendiest new tools. A sound understanding of software engineering practices and methodologies is far more important.
Being adaptable is a must. There's no reason to place a lot of value on a person who has already learned a particular library when you know they will eventually have to learn something else. Value the engineer underneath the layer of buzzwords.