7 ms·

Not trying to defend inexperienced programmers but I've seen plenty of 20+ year senior programmers contribute poorly to SPAs. They refuse to learn the best pra

Not trying to defend inexperienced programmers but I've seen plenty of 20+ year senior programmers contribute poorly to SPAs. They refuse to learn the best practices / new patterns because "they have 20+ years experience". I have been caught in the middle between some younger programmers and some elder folks for the body of the past 3 years and the bottom line is this: Learn the suggested best practices, or just don't build apps like this. The OP's original thoughts on simplicity do ring true, but pushing for better UX is actually a reason to redo something. There are plenty of legacy systems out there with frustrated users, and the "complexity" can be simplified if effort is invested to accomplish those goals.

jrs95 9y ago
As a relatively junior developer, my advice would be “learn the best practices, or don’t write code at all”... But we’ll see if I’m actually following my own advice 15 years from now. Hopefully I’m not on the wrong side of the Dunning-Krueger effect
- neosavvy 9y ago
  Sometimes I find myself fighting the framework and someone inevitably shows me the best practice and I see how it would have just worked had I done more reading. Good luck out there.
- at-fates-hands 9y ago
  > But we’ll see if I’m actually following my own advice 15 years from now. The one thing I've learned after doing this for 5 years is you probably won't be needing to follow best practices in the next 3 months. I've been in my current role about three years. Most of my 2015 was building an Angular 1.X transactional app. By the time it was released, I was told to start learning HapiJS and EmberJS because we were transitioning as a group to that. Then 8 months later and several smaller apps, I was told we're going back to AngularJS and Angular 2.0 transitional. So I had to almost completely relearn that. Then after one huge disaster trying to integrate it into our services, we gave it up and spent the rest of 2016 moving that app to ReactJS. I then spent most of last year jumping around (because now all these apps we built needed supporting) between those three frameworks (Angular, React and Hapi). Now there's talk of moving to VueJS but there is a loud push to just stick with one (Angular or React) and be done with this. My point here is you may want to learn best practices, but how fast my org was changing, and building things quite literally on the fly, you just don't have time. Sure, in my own private projects, I learn best practices and use them myself. For our customers and "the business"? No time man, no matter if it will us time or not. Getting something shipped that's working is far more important.
  - Silhouette 9y ago
    Ironically, you've just provided an excellent illustration of some real good practices: find tools that are good enough to do the job, only depend on things that are built to last, and concentrate on actually doing that job. The web development world's obsession with constantly moving to the next thing that does essentially the same job as the last thing but maybe 5% better (or maybe not) is a huge productivity sink and best avoided as much as possible. Getting something shipped that's working is far more important than exactly how you made it, and it always has been. If "best practices" aren't helping with that, are they really best practices at all?
    - jrs95 9y ago
      While this is generally true, the situation with SPAs is a bit more complicated. Each popular approach early on had a lot of serious issues and pitfalls. IMO React was the first thing to really break through this and while it’s not perfect it addressed the biggest issues Angular and Ember had quite well. However, at this point, once you’ve adopted React, NG2, Ember 2.x, or Vue, there’s not much to be gained by switching between them. They’ve all sort of gotten past the initial immaturities of the SPA approach. This is really something you ought to carefully evaluate once and be done with it.
  - Can_Not 9y ago
    It sounds like your leadership is morons, but you blamed JavaScript?
- msie 9y ago
  Yeah but as a result you could easily write no code at all and not learn from your mistakes.
- Silhouette 9y ago
  The trouble is that web development is such a young field and moves so fast (or at least appears to) that the whole idea of "best practices" is fallacious. In many areas, we barely have enough experience to distinguish good practices from bad ones. Even then, most of the good practices that will stand the test of time are about much more fundamental things than which framework or build tool you're using.
  - jrs95 9y ago
    It’s definitely not about frameworks or build tools. It’s just about applying whatever you’re using well. It certainly doesn’t have to be perfect, but it should at least be clear that an effort was made.
- nol13 9y ago
  would work with. don't care if you use them, but at least learn them!
msie 9y ago
If bad behaving SPAs are commonplace then there is still a lot of work to be done to improve the tools and frameworks. But after many years of churn in tools maybe the problem runs deeper: the language and platform. I wonder if my time is best spent in this field.
SadWebDeveloper 9y ago
Problem: Best practices change every 5-year, new patterns get deprecated by the hot-new opinionated framework at the moment. As a senior programmer is difficult to explain to jr's and sophomores to not look all problems with the "disrupt everything" mentality and have continuous battles about that we don't need TDD, that we don't need CI, that we don't built everything as a webpage and definitely don't need slack integration for everything. jr's and sophomores tend to go trendy on software development, don't like to work on the boring stuff, the stuff that makes money (audit and management, government compliance and payroll software) prefer to go on FB and built the hot-new AI for choosing the right ad to show you.
- kristiandupont 9y ago
  As a fellow "senior" programmer, I can barely imagine a non-side project that is small enough for me not to demand it running on CI.
  - eropple 9y ago
    Agreed. My home server has a Concourse instance on it because setting it to run tests on projects takes, like...five minutes of editing a template. But, then, horror of horrors, it makes it incumbent upon me to write tests, and clearly that's just horrible. ;)
  - Silhouette 9y ago
    As another "senior", I think these things almost always depend on context. Some of the shiny new tools and techniques really do move the field in a significant way. Most of them don't. The ones that do might advance one area but might not be particularly relevant or helpful in other areas. For example, personally I find it easy to imagine projects that don't have much need for CI tools, particularly not the formal ones that have "CI" in their name. Maybe a project is small enough that the only developer(s) involved are constantly making builds for test purposes and rebasing is standard practice when pushing to shared branches. Maybe a very large project has a complicated and carefully controlled branch/merge plan for their repository, and merges at key points are systematically checked following a whole review process. Either way, the extra effort to run a dedicated CI tool might not provide much benefit. Of course, in other cases, you'll be in a sweet spot for this kind of tool. Having something to automatically warn you if a key branch stops building could save a significant amount of time and trouble. The point is that it depends on your situation. Automating something means finding, learning and deploying software and infrastructure to do that job for your particular project. That's time and resources you aren't spending on something else, and these things are always trade-offs.
intrasight 9y ago
That makes no sense. What other "practice" besides "best" would they be using, given that SPA didn't exist 20 years ago? Would they look at the SPA sample and say "I see that you're using history to have the back button work, but I'm removing that code"? Obviously not.

jrs95 9y ago

As a relatively junior developer, my advice would be “learn the best practices, or don’t write code at all”... But we’ll see if I’m actually following my own advice 15 years from now. Hopefully I’m not on the wrong side of the Dunning-Krueger effect

neosavvy 9y ago
Sometimes I find myself fighting the framework and someone inevitably shows me the best practice and I see how it would have just worked had I done more reading. Good luck out there.
at-fates-hands 9y ago
> But we’ll see if I’m actually following my own advice 15 years from now. The one thing I've learned after doing this for 5 years is you probably won't be needing to follow best practices in the next 3 months. I've been in my current role about three years. Most of my 2015 was building an Angular 1.X transactional app. By the time it was released, I was told to start learning HapiJS and EmberJS because we were transitioning as a group to that. Then 8 months later and several smaller apps, I was told we're going back to AngularJS and Angular 2.0 transitional. So I had to almost completely relearn that. Then after one huge disaster trying to integrate it into our services, we gave it up and spent the rest of 2016 moving that app to ReactJS. I then spent most of last year jumping around (because now all these apps we built needed supporting) between those three frameworks (Angular, React and Hapi). Now there's talk of moving to VueJS but there is a loud push to just stick with one (Angular or React) and be done with this. My point here is you may want to learn best practices, but how fast my org was changing, and building things quite literally on the fly, you just don't have time. Sure, in my own private projects, I learn best practices and use them myself. For our customers and "the business"? No time man, no matter if it will us time or not. Getting something shipped that's working is far more important.
- Silhouette 9y ago
  Ironically, you've just provided an excellent illustration of some real good practices: find tools that are good enough to do the job, only depend on things that are built to last, and concentrate on actually doing that job. The web development world's obsession with constantly moving to the next thing that does essentially the same job as the last thing but maybe 5% better (or maybe not) is a huge productivity sink and best avoided as much as possible. Getting something shipped that's working is far more important than exactly how you made it, and it always has been. If "best practices" aren't helping with that, are they really best practices at all?
  - jrs95 9y ago
    While this is generally true, the situation with SPAs is a bit more complicated. Each popular approach early on had a lot of serious issues and pitfalls. IMO React was the first thing to really break through this and while it’s not perfect it addressed the biggest issues Angular and Ember had quite well. However, at this point, once you’ve adopted React, NG2, Ember 2.x, or Vue, there’s not much to be gained by switching between them. They’ve all sort of gotten past the initial immaturities of the SPA approach. This is really something you ought to carefully evaluate once and be done with it.
- Can_Not 9y ago
  It sounds like your leadership is morons, but you blamed JavaScript?
msie 9y ago
Yeah but as a result you could easily write no code at all and not learn from your mistakes.
Silhouette 9y ago
The trouble is that web development is such a young field and moves so fast (or at least appears to) that the whole idea of "best practices" is fallacious. In many areas, we barely have enough experience to distinguish good practices from bad ones. Even then, most of the good practices that will stand the test of time are about much more fundamental things than which framework or build tool you're using.
- jrs95 9y ago
  It’s definitely not about frameworks or build tools. It’s just about applying whatever you’re using well. It certainly doesn’t have to be perfect, but it should at least be clear that an effort was made.
nol13 9y ago
would work with. don't care if you use them, but at least learn them!

msie 9y ago

If bad behaving SPAs are commonplace then there is still a lot of work to be done to improve the tools and frameworks. But after many years of churn in tools maybe the problem runs deeper: the language and platform. I wonder if my time is best spent in this field.

SadWebDeveloper 9y ago

Problem: Best practices change every 5-year, new patterns get deprecated by the hot-new opinionated framework at the moment. As a senior programmer is difficult to explain to jr's and sophomores to not look all problems with the "disrupt everything" mentality and have continuous battles about that we don't need TDD, that we don't need CI, that we don't built everything as a webpage and definitely don't need slack integration for everything. jr's and sophomores tend to go trendy on software development, don't like to work on the boring stuff, the stuff that makes money (audit and management, government compliance and payroll software) prefer to go on FB and built the hot-new AI for choosing the right ad to show you.

kristiandupont 9y ago
As a fellow "senior" programmer, I can barely imagine a non-side project that is small enough for me not to demand it running on CI.
- eropple 9y ago
  Agreed. My home server has a Concourse instance on it because setting it to run tests on projects takes, like...five minutes of editing a template. But, then, horror of horrors, it makes it incumbent upon me to write tests, and clearly that's just horrible. ;)
- Silhouette 9y ago
  As another "senior", I think these things almost always depend on context. Some of the shiny new tools and techniques really do move the field in a significant way. Most of them don't. The ones that do might advance one area but might not be particularly relevant or helpful in other areas. For example, personally I find it easy to imagine projects that don't have much need for CI tools, particularly not the formal ones that have "CI" in their name. Maybe a project is small enough that the only developer(s) involved are constantly making builds for test purposes and rebasing is standard practice when pushing to shared branches. Maybe a very large project has a complicated and carefully controlled branch/merge plan for their repository, and merges at key points are systematically checked following a whole review process. Either way, the extra effort to run a dedicated CI tool might not provide much benefit. Of course, in other cases, you'll be in a sweet spot for this kind of tool. Having something to automatically warn you if a key branch stops building could save a significant amount of time and trouble. The point is that it depends on your situation. Automating something means finding, learning and deploying software and infrastructure to do that job for your particular project. That's time and resources you aren't spending on something else, and these things are always trade-offs.

intrasight 9y ago

That makes no sense. What other "practice" besides "best" would they be using, given that SPA didn't exist 20 years ago? Would they look at the SPA sample and say "I see that you're using history to have the back button work, but I'm removing that code"? Obviously not.