3 ms·

I've seen the sentiment expressed before and I think it will only get worse in the future. React now is very popular with smaller/medium companies, large enterp

I've seen the sentiment expressed before and I think it will only get worse in the future. React now is very popular with smaller/medium companies, large enterprises like banks will surely jump to it after some delay. It's usually when the main talent moves off to something more exciting (what happened with rails -> node for example). Even now it's hard to find someone good at idiomatic React, imagine the same situation when it's perhaps not as popular as it once was and internal projects are mature. Codebases using declarative style are very hard for majority of programmers to grok in my experience, mostly because it's such a big paradigm shift and requires truly abstract thinking, also not generally something you learn at CS programs. It will either all be a big mess or require some senior high salaried people do the maintenance. That will be a good time to do frontend contracting for the enterprises and it's coming soon.

erikpukinskis 8y ago
I find declarative style hard because you can’t use a debugger, which means you can’t “go in and look around”. You need to have a theory of what’s happening a priori that you can test. That means you need to model the internals of the tools in your mind to be able to make guesses. That means a slow learning curve. That’s fine if it’s one of one or two major libraries that you use all the time every day. But in practice most of us are using dozens and dozens of tools, tools which change all the time, and we have to learn as we go. So these “big learning up front” APIs are just not very ergonomic for teams to engage. Unless you’re Rails or React or something where you can claim to be basically a programming language or “standard library” in your own right, something everyone on a team will have already dedicated themselves to studying in depth.

erikpukinskis 8y ago

I find declarative style hard because you can’t use a debugger, which means you can’t “go in and look around”. You need to have a theory of what’s happening a priori that you can test. That means you need to model the internals of the tools in your mind to be able to make guesses. That means a slow learning curve. That’s fine if it’s one of one or two major libraries that you use all the time every day. But in practice most of us are using dozens and dozens of tools, tools which change all the time, and we have to learn as we go. So these “big learning up front” APIs are just not very ergonomic for teams to engage. Unless you’re Rails or React or something where you can claim to be basically a programming language or “standard library” in your own right, something everyone on a team will have already dedicated themselves to studying in depth.