Yes, and I love it.

In hindsight I have been guilty of resume-padding and falling prey to hype by choosing to build on technology not appropriate to the problems at hand. And I find myself reverting back to basics, with bits of new tech sprinkled in.

My reversions:

  - React, flux, redux ---->  jQuery and intercoolerjs when needed
  - Swarm, Kubernetes  ---->  Just plain old docker on single machine, scale vertically with cores and memory when needed
  - Microservices first ----> Django Monolith first, then break out microservice when needed
  - API Gateways (kong, Azure) ----> Nginx reverse proxy with hand-edited configs.

I can do this because I have chosen to work on niche problems and smaller markets. Scale is not my issue, even in very successful scenarios.

I see jQuery will have a place in my stack for some time to come. It just works (tm), and it plays well when I need to level-up with wither intercooler or yes -- backbone.

Another benefit is that it is a low barrier to entry for junior developers. It allows me to establish a baseline knowledge, and then mentor other things like workflow, code structure, and architectural things rather than chasing weird configuration things inside of webpack or the taskrunner-du-jour.

Your reversions resonate with me very strongly, even down to the exact tech choices. While the industry seems to chase ever increasing complexity, I believe 90% of web applications would be served more than adequately by jQuery, intercoolerjs and Django running in a single container that can scale horizontally if necessary on Elasticbeanstalk. (eb deploy.. Done).

But, sadly, it feels like openly selling yourself as a consultant in these technologies would be a form of sabotage and limit your opportunities considerably.

I've just had an idea for branding myself: artisinal, vintage web development using traditional jQuery / Django. :)

I might agree with you and your parent. My objection would be that I all too often experienced that seemingly small projects turned out to grow into huge applications. And previously accumulated tech debt is hard to get rid off. So I mostly start out now with my own boilerplates. React + Redux is one git clone command. Docker including Service Discovery (Traefic, Registrator), RabbitMQ and MongoDB is another git clone [1]. So I am productive immediately and the right tech is in place.

Regarding the discussion Micro-Service vs Monoliths. I agree that a monoliths gets you started quicker. But it also asks a lot of discipline from the programmers. E.g. 'stick to your domain boundaries', 'Don't take that shortcut of direct db access because business needed the feature yesterday', etc. Otherwise you'll have big troubles splitting it up later on. [2].

I REALLY REALLY REALLY like that micro-services make your boundaries explicit and enforce you to write contractual APIs aka Interfaces. Much more than all the promises of scalability etc.

[1] https://github.com/MarkusPfundstein/microservice-service-dis... [2] https://martinfowler.com/bliki/MonolithFirst.html

Question - how long does it take for your projects to “grow into” the stack and complexity you have scaffolded up around it?

If I look at the last two, it was 6 month and 9 month. The first one was initially thought to be just another search engine for some of the company's content. Then it got transformed into the main data store including CMS and all those nicetees. In the end, 7 people worked on it. The second one was a tool used only internally by my customer's employees. They then sold the idea to some of their customers and it had to transform into a full fledged product. 4 people are now in charge of it.

I am still coming back to projects sometimes where I didn't do this and I hate every minute hacking on them -.- 'Wish I would have just used React or whatever' are often my thoughts then :-)

How are those big projects? Why would you need any scalability for that?

From what you just said they're running for, at most, a few thousand people.

In terms of loads/numbers/etc. that's child's play and definitely not "huge applications". The kind of decisions he's talking about are for things with thousands of concurrent users per second, not per day.

That kind of stuff could be dealt with a single desktop computer running PHP and mysql. And you definitely don't need microservices.

In my experience, having worked in both enterprise and consumer startups, enterprise is shallow but broad with little need for any of the complicated stuff and more need to make the code really simple, obvious and uncomplex because it ends up dealing with so many different problems, while consumer scale is where you start needing to get a bit fancy purely because of scale, but it only deals with a couple of problems.

To quote myself regarding micro-services: "I REALLY REALLY REALLY like that micro-services make your boundaries explicit and enforce you to write contractual APIs aka Interfaces. Much more than all the promises of scalability etc."

With huge applications, I mean 10s of thousands of lines of code with features added on a daily basis by multiple developers.

What both have in common is that they started us as seemingly small 'throwaway tools' but grew into business scale applications that serve now a core purpose.

Btw, who said I didn't use MySQL and PHP ? :D

Again, "10s of thousands" of lines of code is nothing. It's a few months work.

Introducing microservices into a small code base feels like it would be counter-productive. It adds a ton of unnecessary complexity to a tiny code base.

You don't want contractual APIs for code like that, as it grows the contracts are going to be constantly breaking as new features are added and the only people who care are the other, internal, developers.

If you used a statically typed language, in a monolith it would tell you immediately that it had happened as soon as you did your sync (which should be happening multiple times a day for everyone). Better still, the other developer would have had to deal with it, the only code you'd need to worry about is the new code you added, and again, your check in would break the build.

Code how you want, but my mind boggles at people doing microservices for tiny code bases. Much better to have a monolith until you get into the million of lines.

I am just thankful I work on statically typed monoliths where my tools just deal with it and I don't have to spend time setting up and debugging microservices instead of doing actual work.

“You don’t want ...”

Thanks for telling me what I want :-) I also worked on statically typed monoliths (.Net)! I also worked on micro service systems (>70 services, 2 years of work) written in NodeJs.

It all has its pros and cons.

Calling jquery “vintage” is like playing Coldplay on the oldies station.

Sure, but there is a bit of relativism here, isn't there? A 10 year-old might consider Coldplay an oldie the same way a fresh javascript developer might consider jquery old legacy stuff despite the fact that both continue to make releases.

I think if you are selling services as a consultant then perhaps sell the solution rather than the technology behind it.

When I buy a car I’m buying the benefit of it, which is convenient transportation. I don’t really think that I’m buying a drive train, engine, steel body, airbags and whatnot.

How do you deploy updates to the docker containers without downtime?

For example with Docker Swarm: http://container-solutions.com/rolling-updates-with-docker-s...

Some companies have GitLab workflows that also deploy successfull builds automatically, checks are there problems in that deploy, and rollbacks automatically when needed: https://twit.tv/shows/floss-weekly/episodes/473?autostart=fa...

Such workflows could also be made with for example: - Huginn https://github.com/huginn/huginn - Flogo http://www.flogo.io

Well, the trick is that I have downtime but it last for only a few seconds.

  Docker pull <image name>
  Docker container stop <container name>
  Docker run <opts> <image name>

This does result in a “hiccup” for any clients wanting to connect. They will see a 502 gateway error at which point they should retry with exponential backoff.

And that is the trick — make the client retry with the exponential backoff. Document it as the expected behavior when that event arises. And for our traffic patterns this is acceptable.

I would be surprised if a majority of new projects with a JavaScript library weren't using jQuery. I personally moved on a few years ago and I suspect that's the case with many people who respond on HN, but there are still plenty of valid use cases, particularly when JS needs are simple and backwards compatibility is really important.

If you're doing projects with light functionality and already know jQuery cold, you really don't gain much from React, Vue, et al for that project. You may gain something personally (career path, different way of thinking, etc), but that is a different topic.

For anything slightly above the basics, I'd recommend Vue as a great alternative to jQuery. No build tools required and it's easy to stay in the realm of plain HTML, CSS, and JS. It also "progresses" really nicely if you have more complex needs later on -- that would be a main benefit over a tool like jQuery.

What you used jQuery for hasn't so much been replaced by React and what not, as it has by native Javascript. Most of the things you used to do through jQuery are done with regular Javascript (and DOM API's) just as easy nowadays - depending on your browser demographics, of course, but will be fine most of the time.

Of course. We're not all mobile app developers on HN. Some of us still make small info sites, or prototypes. And me, I'm actually a backend sysop but my hobby of developing websites keeps me branching out. So I've never developed a web/mobile app with a framework, and still use jquery for simple websites.

You are right that jQuery is dying:

https://trends.google.com/trends/explore?date=today%205-y&q=...

5 years ago, jQuery was twice as popular than it is today. But I wouldn't call it dead just yet. It's a work in progress.

By the way - one of the things that killed jQuery is HTML5, it's not only Vue and React for more advanced features, a lot of people used jQuery for basic DOM manipulation, which today you can probably get away with just fine with the HTML5 DOM API, since the addition of the querySelector APIs and things like CSS's classList APIs.

Yes, for almost all projects I work on due to the plugin ecosystem. If size is a concern I will look at zepto, a smaller 80/20 implementation of the jQuery API. And I almost always use intercooler.js to keep my js footprint small.

querySelector + classList + CSS transitions + fetch absolutely destroyed jQuery.

And Web Components are starting to destroy jQuery Plugins.

The company I work at uses jQuery for most DOM manipulation. I'm a backend developer and already knew it a bit so it's easier for me than using React for simple things. I don't do any frontend outside of work, so I've never gone past the React tutorial on my own time, and I suspect many mainly-backend developers have a similar story.

Yes. I use it especially for Wordpress custom themes or small websites or web apps that rely on DataTables.

It depends on the project. For web applications and SPA I prefer using React. For ecommerce and smaller projects, the stack is jQuery for cross browser (and old browser) compatibility with the minimum effort.(And Vue for some commerce components like minicart, quickview etc)

Not so much. It's lost out at both ends. Larger projects end up with Vue (and before that Angular), and smaller projects end up with just VanillaJS due to support for APIs like document.querySelector(), window.fetch(), <input type="date">, etc.

I stopped using jQuery after I started a rather large Angular project 2 years ago.

Since then, I had one project where using jQuery and jQuery UI was dramatically easier than building out a datepicker input by hand; however, for everything else, vanilla js is my go to.

Almost every older project I've worked on uses jQuery. Currently working on a large Rails app, some parts being 10 years old, and it's the same story. Old code is jQuery, new code is not.

It was spectacular 10 years ago, but now it's pretty much useless to me. Most everything either shouldn't be done in javascript or has a native replacement – at least with polyfills and Babel that I need for all development. I would love to remove it, but it would take far too long and provide little customer benefit (remove the library download), so it's only removed when something is refactored.

I just use JQuery and a few other libraries as needed as I use ASP.NET MVC so that takes care of the backend, no need for ugly, complex JS, keep it as minimal and simple as possible. If things need to be done more intensely in front end I use Knockout which seems to be very good at what it does and doesn't muck it up by offering more than it needs or is meant for.

I'm using jQuery for a platform that I am launching very soon. The javascript/jQuery portion of it currently stands at 63k LOC. I would not be surprised when I finish, it'll stand at over 100k LOC.

If I look at the number of open source 3rd party js libs that support it, they are around 180k LOC.

Eventually, I do see a project that ports over the entire js code over to ES6 and Vue.

Absolutely! Different tools for different projects. If I'm building a 'real' webapp (as in, something with users logging in and lots of data dependencies) I'll use something like React, but if it's a small project... it's not at all worth setting up the infrastructure and maintaining it when a few lines of jQuery will do the job.

Yes. I think it is faster to develop in general for small sites.

When it becomes very much not faster is when you have a bunch of jQuery poorly (or "customly") organized and someone else has to wade back through.

Vue is awesome though, really liking it. Sometimes I use Vue and jQuery together to take advantage of jQuery plugins. Does this make me a bad person?

Yes, it is a good tool for one of my projects where I need to cleanup some html, is very good for DOM manipulation. It is also a very good tool for simple webpages, If I have some mostly static thing that I need to show I can render that on the server with PHP and have jQuery insert it on the right place and handle some events,

Yes. I'm currently using JQuery+HandlebarsJS as a poor man's model view framework. I create the interface with Handlebars + Bootstrap, use JQuery to call an api when necessary. The template also has the necessary JavaScript event/function inline.

Yes, still haven't really ever seen the need to use React yet.

Of course. It still works right? :) Probably there are experts on Jquery, and although they are probably learning new technologies, when needed they rely on their expertise.

I've literally only used it for .animate() in the past 6 months. VueJS came and took over. Might be time to think about pulling jQUery out..

I use it alongside Marionettejs. Not my first choice of technology but works great for extending the framework with a plugin or two

As a matter of fact, I write terrible Javascript all the time throw jQuery all over the place.

My end users don't care! YMMV

"have taken over most of the mindshare"

Have you got numbers to support that? Because I think it's wrong.

It's only my impression, really. But I have seen a slew of articles about how jQuery is dead, and very few people still writing articles about it's benefits. Many libraries that use it are also unmaintained now (though they often still work, of course).

If you want some numbers, compare e.g. the dates on popular HN posts for jquery[1] vs react[2] and vue[3]. Most popular articles for jQuery are 4-6 years old, while for React and Vue the popular stories are much more recent. Of course, HN might be somewhat special.

[1]: https://hn.algolia.com/?query=jquery [2]: https://hn.algolia.com/?query=react [3]: https://hn.algolia.com/?query=vue

HN represents current dev trends like reddit represents current social trends.

How many new articles do you see about C/C++? Blog hype does not represent language strength or longevity.

"Only new and overhyped platforms don’t have problems, because nobody cares enough yet to discover them"