What does that even mean?
jQuery is library that provides DOM shorthand - it isn’t a true application framework.
I haven't found that to be a major issue. And I don't think the term "refactor" is the best choice here.
jQuery is library that provides DOM shorthand - it isn’t a true application framework.
Of course not. I don't want a third-party application framework. I discovered years ago that they're not worth the extra effort or the technical debt one incurs with them. (At least not to me. I'm not telling anyone what they should think or that they should design their applications like I do.)
My approach for me and the developers on my team is to develop a deep level of understanding of HTML, CSS and JS. Once you have that, the prospect of doing things for yourself that frameworks would otherwise provide does not seem all that daunting. To me, frameworks like React, Angular, etc. don't reduce complexity, they increase it.
And I hasten to note that I realize that many bright, capable people hold a different view , and I'm not saying they're wrong.
How does functional, side-effect-free code increase complexity? What makes your side-effecting code more testable and verifiable than unambiguous in/out functional transforms?
With jQuery and such you just include a script and back then there were no package management system, glup/grunt, webpack, yeoman/brunch, etc..
Also the client side rendering make SEO hard.
jQuery just get stuff done but at the same time the organization of your code is up to you and you do sacrifice some reusability but in general the trade off is complexity.
VueJS as much as I love learning this framework, it is complex with webpack, cli, browser plugin, and etc...
"Just get things done" when the way you're doing so is less clear, less testable, and less reliable is not, to me, the hallmark of a developer I would trust with anything I cared about.
If your project is simple, webpack setup is copy/paste (v3) or no config at all (v4). If your project is doing complex stuff, webpack is more in-depth, but a breeze compared to the make files and XML config of other languages. More importantly, webpack has a very clear tutorial and extensive documentation. You have to go incredibly far off the normal path to run into something that isn't covered. Off topic, but augmenting webpack dev server express instance made dev work many times easier on my current project.
Not to dig on Angular too much, I think it's fine, but I'd much rather use Vue if I was going for small, or React if I'm going for larger interactions/components/applications. Angular does have a lot in the box, but when it takes 4 guys to lift that box, there's a lot less value than 4 smaller boxes.
This defines what the developer wants to happen, but is brittle and hard to test. Frameworks would typically break this into actions or methods that modify state and a UI that updates when the state changes, so that the parts can be effectively unit tested and the UI can be changed without touching the rest of the logic.
This is possible to do with jQuery too, but the library doesn’t do anything to help you. This is one of the primary complaints levelled at React, too.
This defines what the developer wants to happen,
Yes, it does. All in one place, in about 10 easy to understand, easy to debug lines of code.
>but is brittle and hard to test.
I don't see how it's brittle, or hard to test. You click the button, and verify that it does what it's supposed to. Having done it more times than I can possibly count, and ending up with robust code, shipped on time, I can tell you that it's not hard, if you know how to do it.
> Frameworks would typically break this into actions or methods that modify state and a UI that updates when the state changes,
Which, IMO, makes something simple to understand and dead simple to debug into something painfully, ridiculously complex. And people complain about "jQuery spaghetti code".
>so that the parts can be effectively unit tested and the UI can be changed without touching the rest of the logic.
You cannot effectively unit test UI code, if by effective, you mean that it can replace manual testing. It can't replace manual testing. Someone will have to click that button under all of the likely scenarios and verify that it works. I'm sure it's not to you, but to me, writing unit tests for UI code would be a massive waste of time.
If someone thinks they can be more productive using JS frameworks, and I don't have any personal financial stake in their productivity, then they should use them. But I don't see web development using a few simple tools like jQuery as difficult or mysterious or time-consuming.
Last year I interviewed a few recent boot camp grads and they all sent me a link to their copy of the same React-based project. When I asked them questions about how things worked, in generic terms, for example, "what do you think makes this picture slide down slightly and expand in size when I mouse over it", they had no clue. I guess it was just a React component they dropped in, following the steps in the tutorial. I'm not faulting those people -- they paid a lot of money and did exactly what they were told they needed to do to land a sweet high-paying programming job. But they're simply of no use to me. I need the one who looks at it and knows right away that it would take about 4 lines of CSS to accomplish, even if they had to consult a CSS reference to find out exactly which properties/values to use.
For sure. We have a team of people dedicated to testing. Compared to developers, they're easier and cheaper to hire. Our developers, who are very brilliant and very expensive, mainly write code for production, and leave testing to the testers. They write code designed to run efficiently and be maintainable, not to be more amenable to unit-testing.
This has proven to work extremely well for us. If you need unit testing to ship robust code in a short timeframe, it would be foolish for you to not write the unit tests. But our team culture is such that we don't do things that we don't need to do to be productive and successful, and unit testing is one of those things.
That's strictly your opinion, which I do not happen to share.
In the end, I'll take my single state tree (source of truth) and one-way rendering path, and find it much more sane, without weird state and interaction bugs that show up.
I have. Without problems.
>In practice, CSS blows up, other portions of the app stop working correctly.
Perhaps in your practice, tracker1. But not in mine.
That's what everyone seems to be missing here. This is all a bunch of hand waving to me, because I have a lot of experience shipping a lot of robust, maintainable code, and none of it has been true for me.
If you need all of this stuff to ship robust, maintainable code, then you would be foolish not to use it. But I would be foolish to use some complex framework that I do not need to ship robust, maintainable code.
I think the facade is starting to crack with many of these JS frameworks. More and more people are writing articles like the OP and saying that this particular emperor has no clothes.
Ave you ever had to work on an application that's more than 5 years old, with an active dev team of 30+ (just the web developers) that have had over 200 hands in the pie including contractors then? I have, and it was a nightmare. Frameworks and modern tools help to take care in these situations.
The application above was around 2007-2008 IIRC... different parts made by different teams, cobbled together. Layers of backend cruft as well. I did help start a new project, that had much more consistent/clean structure. But when you have too many hands in a pie, and no automated testing in place, you wind up with that eventually.
I've been developing web based applications since 1996. I've lived through the eras without the browsers and abilities we have today... the growth of the DOM and the JS language from a few interfaces for forms, to being able to do so very much.
You don't have to use anything to ship your code... but you have to do something to get a few dozen devs working on something cohesive.
I was a rank and file developer on a similar shit show years ago. The main difference was that it was a greenfield project at a startup. The people calling the shots were dead set on using the latest fads -- at the time it was the Rational Unified Process, with all the attendant documentation, and EJBs. I knew that Entity Beans were a monumentally stupid idea when I first read the O'Reilly book about them. And I said so, to anyone who would listen, to no avail. I think the team reached 40 developers at its peak, of which maybe half were totally incompetent. (By my standards.) The schedule slipped rapidly, we were put on mandatory 6 day work weeks, I bailed out, easily finding another job, and eventually the whole project cratered.
I'm not going to argue with your experience, tracker1, but all of my experience tells me that the ability of the developers is the best predictor of the outcome of a software development project. And our profession, unfortunately, is awash with incompetent people. For example, people who have worked for over 5 years as a Java developer, who are unable to write a Hello World program in Java from scratch in a plain text editor, and compile it and run it from the command line.
That said, I'm not saying no frameworks/libraries/tools, and am okay minimizing. But I'd rather use Vue, React, Redux and other libraries/patterns than not in most cases, and find them better overall than ad-hoc jQuery. And don't get me wrong, I've written a lot of ad-hoc and organized code without modern tooling. I'll take today's module systems, builders and bundlers.
As to Java hello world, frankly every time I've had to touch a Java project, it takes 2-3 days to get a build environment running on a local dev machine... it's nightmarish. I've never even taken to learning Java from scratch my exposure has been so bad. I did learn C# from the command line compiler and a book early on, I didn't have VS to hold my hand. I later did learn VS etc, and that was nicer still.
Getting the pieces together with node/js has been difficult, and painful and a slow process even keeping up with node since it was first announced in 2009. It's taken effort. But anything more than a quick demo, I'd rather have it. I'll leave TypeScript/flow and similar alone though, I don't think they bring more than they take most of the time.
I realize I'm outside the mainstream schools of thought. My approach to developing software absolutely depends on having a rare and special kind of developer doing the work. The emphasis is on deep expertise in the core technologies - JS, HTML and CSS -- that will stay around while fads come and go. And quite frankly, my approach does not scale well. It's not that I couldn't keep 40 developers of the caliber I require productive, it's just nigh on impossible for a non-Google-class company to hire that many in one place. (Considering all you've heard about Google's hiring process, imagine how much it costs them to hire a single developer -- even before the first paycheck is cut.)
>As to Java hello world, frankly every time I've had to touch a Java project, it takes 2-3 days to get a build environment running on a local dev machine... it's nightmarish. I've never even taken to learning Java from scratch my exposure has been so bad.
Maybe you're reversing cause and effect. Maybe your exposure has been so bad because you've never made the effort to learn it from scratch.
When I adopt a technology for use, I go really deep. I'll get a book, start on page 1, and work through it to the end. (Sometimes I might deem the last few chapters skippable.) After a few months I'll re-read parts of it as a refresher. (That has proven super-helpful.)
That's why I think Reactjs and its like are a lot of fuss and bother to do something that I can already do easily with a lot fewer moving parts. And also, if I decide to use React, I, and (perhaps to a slightly lesser extent) my developers, will go deep into it, and that takes a lot of time and effort. So I have to be very judicious in what new shiny thing I go chasing after. I need to see an obvious, significant return on that type of investment. (I don't care about my resume having the latest buzzwords.) And I just don't see it with any of these frameworks.
I’ve seen 10,000 line single jquery files handed off to other teams who were asked to merge them into their 4,000 loc customized quasi consumer of the 10,000 loc file. This was at a well respected and iconic tech company with very smart engineers.
Even good people and teams can suck at architecture.
I’ve taken those codebases and refactored them to be testable so I know it’s possible. But why not just use something sane like react to begin with, considering it’s 2018 now. At that point, backbone was only a year old.
There were a ton of times where the complexity of the situation made it so hard to know how to debug something. I mean you had to keep track in your head in a given piece of code what the UI state was, what classes or event handlers were toggled on or off, what the value of various variables were etc. In order to keep my sanity I would have to create functions that basically do what React or other frameworks give you out of the box so it would be easy to reason about everything.
There was so much code like this: var $snippet = $(<div></div>).append(...).addClass().on('click', handler => { if (alienState) { $snippet.off('click') } else { $snippet.on('click', handler2) } }) $(".parentClass > ").remove() /clear any dom framents in there //before a fresh injection! fingers crossed!*/ $(".parentClass").append($snippet)...
etc etc
I'm sure there is a way to do disciplined excellent jquery code. I'm always quick to say its the coder(s) that make a piece of software code good or bad. But if you were to make a well made jquery application you would need to implement some kind of design pattern, and exercise some kind of conventions and discipline that you could really get for free with a framework.
Debugging async code isn't like debugging other code. Once you cross that async barrier, all stack traces disappear (I understand Google's doing some work on making that better).
In this particular case, debugging is harder because the UI is also holding all the data, so in order to reset to known good data, you have to reset the page itself. One of the biggest benefits to moving to React (or similar) is that you start keeping all that data in a central place.