Your thoughts on webpack/babel/grunt/gulp well echo my sentiment towards seasoned programmers.

I've only been at this for around 15+ years right now. I agree I am starting to see repeated problems solved in new JS languages that I've seen solved in the past.

That's part of the fun in what we do for a living though. I consider myself at least mildly seasoned, but still a ton to learn from those fresh to the field and those who have been around the block at least twice.

I quite well understand what WebPack is doing, and find it very useful. Anytime I find myself thinking I'll make my own recipe for a build system with custom scripting, I seek a well supported framework, you know on the off chance someone else wants to understand and contribute to the build system.

I think it's a poor choice frankly to build 100% custom frameworks for building when you can use a widely adopted community choice. I was more pointing to the volatility of JS frameworks vs stable frameworks in Java like Spring.

As we age in our career though it seems we should avoid condescending tones with more junior programmers though, as they may have a unique solution to problems. I've seen some junior folks get quite offended when a non-producing "seasoned" programmer gives them the "I've been doing this for 20 years" schtick, then turn around to spend a few days on a powerpoint instead of contributing to the team.

Anyways, I don't want to rant.

I hear you. Instead of thinking about a build system (custom or not), I normally begin by trying to keep the project simple enough that file copy is my build and deploy mechanism.

I don't mean to be rude, but you clearly aren't talking about the same kind of application. I have worked on a SPA before that used knockout and jquery with an ASP.NET MVC backend and Razor-rendered 'templates'. It was a much different beast than an angular or react app.

I am observing that you are right, there is no definition globally accepted by the community on what an SPA is.

For me, a better definition is the one that it is independent of the technology used to implement it. An SPa is a way to structure an app, is not a vendor feature or a tool.

While is true about nowadays angular et all are the tools commonly used to create SPA, the tool shouldn't have the power to change the definition, so your knockout MVC is still an SPA.

If the OT chose a complicated set of tools to develop an SPA, then is his decision and the difficulty lies in his decision of the tools chosen, not on the SPA type of app.

I agree we aren't talking about the same apps.

I don't know if folks much consider vanilla JS / JQuery apps Single Page Applications.

I think (but am not sure) that all SPAs are built these days with Angular, React, Ember, Elm, Vue, or some other framework I haven't paid attention to.

Usually tied into Restful webservices that don't do any templating server side unless it's via Isomorphic JS. Maybe I got it all wrong though.

None of them? Are you just doing everything vanilla js/html/css with no build tools, or just using bash/npm scripts?

The thing about build tools and frameworks is that once you have tools for managing complexity then the penalty for complexity goes down and complexity explodes.

The apps I have seen built with all of these "modern" tools are much more complex and difficult to maintain than the apps I was seeing 10 years ago that were architected and managed by hand.

That is why many of the people using these tools are switching toolsets every 12 months because they can't maintain what they are creating and have to throw it away.

My experience boils down to inconsistent mindsets on large teams too though.

You get a variety of folks in a room working on a complex business problem, some favor simple tools, some are constantly distracted by shiny new tools, you end up with crazy complexity at times in terms of the solution.

I think it's important to focus on a team and vision for managing the complexity and the rest should fall into place. It boils down to good engineering vision.

Nothing beyond jQuery, Bootstrap at the core.

Sometimes some libraries for UI components like datatables.js, or a datetimepicker, but that it is.

Does anyone else even have a desire to work on the apps you are contributing to with you?

<sarcasm> I guess you must still be living in your parent's basement because you must not have many bills to pay </sarcasm>

LOL

Now seriously:

Quite the opposite, I always receive comments on the simplicity of my code.

Also, I code so the user has a pleasant work experience, and also so the CPU executes the code faster, I don't put much attention to the comfort of the next developer, but I am always willing to show and explain what I did and why.

Wow, ok.

I won't get into a pissing contest, but I've solved and managed large and small teams. Folks don't like to maintain custom built software solutions that don't use common accepted best practice frameworks.

JQuery is widely accepted as an anti-pattern by huge swathes of the programming community.

You are right though, I've paid off most of my bills and do have a choice in what I work on anymore. I definitely don't live in a basement.

I agree about the pissing contest, Just to document the issue: the same way that my sarcasm touched a nerve in you, the comment "Does anyone else even have a desire" can be read as belittling and condescending. But I rather laugh at it with a sarcasm.

I have never been a follower of what the community says. Half of the time figureheads make bold statements based on an economic agenda more than a technical one. If JQuery is an antipattern... don't know, don't care, what I do know is that is light enough, and provide a simple, compatibility layer across browsers. That is good enough for me.

Technically speaking the only reason to avoid JQuery now is because DOM manipulation is more costly than dealing with a more efficient Shadow DOM to manage the lifecycle of UI updates on a screen.

JQuery may be a fast download but JQuery applications can be quite costly to run especially in a non-browser-refresh environment.

I'm sure your JQuery applications are quite efficient, but I am an advocate for choosing modern tools that developers want to work on when you inevitably move on from your projects/customers. I do also advocate for tools that are going to be around to stand the test of time, and in your favor JQuery is a ubiquitous library used all over the place, people do know it, and a customer of yours will have no issue finding someone who is willing to work on it.

I by choice avoid those projects, and have worked with quite a few folks who do things the JQuery way when we are using React or Angular.

Enjoyed the debate today, but my question was largely left unanswered. I was curious if you worked on a large team with your framework/JQuery or if it was a smaller deliverable managed by you and another person or maybe just you.

I have witnessed React and Angular apps with as little as one developer, but up to 30 in some cases all on the same application. Complex applications like Trading Systems and Document delivery with multiple connected users.

I'd wager it's tough to get all of that done without some documented tools and complexity, given the complexity of the business problems at hand.

JQuery is widely accepted as a productive and appropriate tool for many types of projects by huge swathes of the programming community.

I currently help maintain a React app that's approximately a one dev project. It's a beast though. 900 transitive npm dependencies. Huge, brittle build process that has broken in the past and prevented us from deploying critical changes for periods of time while we debugged it. Several long-standing bugs because it's such a hassle to get into. I'm a big fan of jQuery sprinkles in light of this experience.

I think you're conflating React with other complexities. React doesn't require 900 npm dependencies.

Are any of the apps you made public? :)

Also sounds like you’re working in a small group? I’ve found large teams will value clarity and maintainabiliy lots more.

Lots of my work is under very restrictive NDAs, so not much public, all though heavily used internally by my clients.