[0xUser]

Most of the time and in most places use proven, boring, technologies.

There's time and place for using cutting edge solutions. But if that time is 'always' and that place is 'everywhere', you might be doing it wrong.

Keep things simple.

[neovive]

Well said! Over the years working in web development, "Keep it Simple" saved me countless times. Unless a project has strict requirements for a new, novel and/or complex solution, stick with the simplest, proven, heavily-tested option--usually the most boring. When selecting tools for your stack, ask yourself: "How will my end users/customers benefit from this tool?" For example, very few will care if you used Angular, React, Vue or jQuery for your front-end as long as the page works well.

[AtomicPlayboy]

Keep it simple and get the basics right. That's when having good education matters. College won't prepare you to the market in sense of cutting-edge technologies but will give you good basics on "boring" but essential knowledge that helps you think in terms of trade-offs and evaluate new technology properly. So you don't have to shoot yourself in the foot jumping into, say, an Electron bandwagon and writing big, resources-consuming applications when something simpler could suffice or adopting NoSQL and having to deal with the lack of ACID just because "shiny new tech" and "everybody is doing it".

[neovive]

Exactly. I was very close to using Mongo for a project that had mostly relational data and a few unstructured fields. MySQL with a few JSON columns worked much better in the end.

[crash_and_burn]

We asked for a basic inventory management product that would have uniqueness constraints, mainly relational data, and be used by a small group of users. Our devs wanted to test out angular to see if it would speed up development on other projects (fair enough), and pitched dynamoDB on AWS. Angular took just as long or longer as their usual methods, required outside consultants for extra cost, and dynamoDB got us a product that failed uniqueness constraints all over because the devs were unfamiliar with NoSQL as well. I guess it helped with adapting the software quickly and adding fields as new requirements popped up though. Nice experiment, but definitely not something you'd want to have to deliver on a schedule to a customer with strict requirements and a competent QA team.