I found that odd. I do worry that many people use technologies because other people working at a completely different scale or in a completely different domain have hit a ceiling which wouldn't really apply to most people. They are convinced to start with a more complex and more difficult technology that's solving problems they are unlikely to be facing any time soon.
1. NoSQL <> traditional RDMS because of scaling/sharding
2. Angular <> jQuery (or anything similarly lightweight) because of the issues around huge complex webapps
3. 'Fast' languages <> 'nice' languages ( ;-) ) because of performance concerns
4. Static typing <> Dynamic typing because of maintainability across large teams.
5. Docker/Microservices etc <> traditional architectures because of... I really have no idea...
So I guess the degenerate case is some poor chap learning web development who decides to write their Pet Store as an angular app with a Scala API backed by Mongo and Solr deployed to a Kubernates cluster ;-)
My friend was brought in by a client after the previous contractor had spent 300+ hours coding a simple organizational website - here is who we are, here is our phone number - using node.js. I doubt the website will ever see more than 20 concurrent visitors.
Even still, that's just the completely wrong technology to use for something like this regardless of scale. It sounds like it's literally static content. Just write an HTML file directly if it's a single page, or use something like `Assemble` to get easily re-usable partial support if you have multiple pages that want to share a header and footer or something.
That's not exactly the way I think of it. I try to be pragmatic about my tech choices, even if I might be wrong at times.
To pick on your NoSQL example. There was one project where I had a large set of records which were all JSON in a text file. There was no one set structure for it. Attempts to set up proper MySQL tables for these records didn't work out so well. It was only after the pain of trying that I decided that MongoDB made more sense for this "collection of documents".
This is a very good point; I also found the submission enlightening for that reason -- because of the 'rediscovery' of jQuery, and how for simple use-cases, it's actually fairly palatable.
All solutions go through a maturity cycle where we invent an ostensibly "better" way of doing it because we're frustrated with the old way -- jQuery came about because early DOM selectors were lacking, Angular came about because people built complicated client-side spaghetti code state machines with jQuery -- but eventually a new wave of people comes along and the 'new way' becomes the 'mainstream way', and the like.
Like this author has done, it's interesting to go back and rediscover how things were done in the past, and in many cases you learn more about the problem domain or your stack of choice by doing so. My age is also showing that Angular no longer counts as cutting-edge, early-adopter tech, but firmly in the camp of mainstream ways of doing client-side code.
I have a suspicion that this kind of thing happens with programmers who have not worked much on client side development moving to it from Enterprise Java development or similar disciplines. This suspicion also seems to be borne out/hinted at by the post.
Nope. jQuery came first. For me, it was a matter of spending a few years in Java shops. Most of the work was so server-side focused that I ended up forgetting a lot of my Javascript.
After leaving my last job, I decided I needed to update my skills and Angular seemed like a good road to go down. It was only recently that I decided to return to the old jQuery well to see what I could do with it vs. Angular. I'm glad I did.
This is an extremely confusing statement, considering that Angular2 is only at RC5 and has had many major breaking changes to the API and core components ranging from 3 completely different router builds, introduction of NgModules, greater integration with Observables, a compiler still being developed, etc all since it left "Beta" in May.
I'd have to guess you left Angular2 to go back to Angular1 considering the current state of development
Not really. I'm more of a backend developer, but around the time it went beta (early 2016) I felt it was a good time to be ahead of the curve. So I started learning it with no Angular 1 experience. I've followed it through the betas and RCs.
I recently picked up Angular 1 just because it seemed like a good idea (I often mentor others), not because Angular 2 wasn't in a good state. (If I had to do a project today, I'd probably go with v1, just because the ecosystem feels richer)
1. NoSQL <> traditional RDMS because of scaling/sharding
2. Angular <> jQuery (or anything similarly lightweight) because of the issues around huge complex webapps
3. 'Fast' languages <> 'nice' languages ( ;-) ) because of performance concerns
4. Static typing <> Dynamic typing because of maintainability across large teams.
5. Docker/Microservices etc <> traditional architectures because of... I really have no idea...
So I guess the degenerate case is some poor chap learning web development who decides to write their Pet Store as an angular app with a Scala API backed by Mongo and Solr deployed to a Kubernates cluster ;-)