How it feels to learn JavaScript in 2016

To me, this topic highlights the difference between a developer/programmer and a software engineer. As a small business owner, If I'm hiring a developer/programmer, I'm looking for specific skill sets in a given language/framework. I don't expect to hire a PHP programmer and throw them into React/Mobx/Webpack/Gulp/Babel/Websockets without a tremendous amount of training. Frankly, I don't even expect them to know SQL in any sort of advanced way. I'm paying less for that person and getting less in return. I'm taking on the challenge of "growing" them into what I want them to be in the future or letting them go if our project pivots

When I hire a software engineer, however, I'm paying more and getting more (hopefully). I expect software engineers to understand engineering principles and be able to work in almost any language. At a foundational level, they understand the basics of compiled vs interpreted languages, OOP vs functional programming, client vs server, optimization, testing, databases, networking, software release life cycle...and how to employ all of those. I expect to give them a business problem and have them develop an entire technical solution using whatever tools are best suited for that job.

In most cases, projects are a good mix of both software engineers and developers/programmers. The two can balance each other out and produce amazing things.

Lastly, everyone should be looking to improve their knowledge of their own industry. If you are a developer/programmer/software engineer, you should be looking at what is new/upcoming in the industry. You need to remain fresh or you become obsolete. In a very small example, the move from Python 2 to Python 3 has been a long road. If you are not aware of the improvements in Python 3 over Python 2, how can you actually determine if Python 3 is a good choice for your project? How can you take advantage of the improvements? What about Go vs Python 3? How does Erlang/Elixir fit in to the equation?

There's some truth to that.

My own experience was in writing a lot of vanilla JS, being pretty happy with it, and then wanting to grow bigger I investigated some of the frameworks. At the time, Angular 1.x was considered the thing, so I implemented a project in that (multiple drag and drop lists, items from lists into other lists, and so on), and tried to follow best practices as far as I could tell. DRY, decoupling, etc. It was pretty horrendous. I ended up with so many different services, service providers, components, dependency injectors, and all kinds of (to me) really quite complex abstract boilerplate that had nothing to do with the actual business problems.

I eventually got it all working, and thought I was doing pretty good. I then took a break from that project and came back to it 2 months later, and couldn't make head nor tail of it. So many angular-specific concepts and terminologies.

I've since come across mithril.js, and found it (for me) perfect. It's designed to let you build stuff really fast, and modularise things around your business logic, rather than have the whole of you application design enforced from the framework. Leo's blog posts https://lhorie.github.io/mithril-blog/ are fantastic, and I think made me understand a lot more of javascript itself, and how to design applications in much more 'well designed, but not framework specific' ways.

> What's wrong with HTML?

Its impossible to share data between JS and HTML without reimplementing parts of JS in HTML from scratch, or rather, implementing a HTML-like template engine from scratch in JS. The model just isn't designed to do what we want it to.

Web components are working on this, except they're reimplementing every modularity feature that JS already provides (HTML imports, shadow dom) from scratch, and then they're implementing every feature that React gives you (custom elements) from scratch. But its still too early, and most tutorials don't show how it works beyond the simplest examples (I would be convinced if I see a data grid component demo with custom item rendering per column which supports passing table data from JS)

What did you you use for the backend?

I've found that settling on a fairly narrow set of tools that will cover most use cases is a good start. "Best tools for the job" is not a good advice in the JS app development... Rather, "Good-enough tools for most situation" has been what I've been telling myself. (The caveat is that I am the only developer in this case, or I am in a position to determine the technology stack for the rest of the team.)

Personal anecdote: I chose React as a starting point as its component model and lifecycle API just clicked better with my mind. I tried Angular 1.x and, while I liked that it defined application structure more, I couldn't motivate myself to study its component model and lifecycle. Things might have changed since Angular 2.x, but I don't want to go through a technology churn again trying it out. Then I noticed React Native plus other spinoffs like React Native for Desktop. Those projects seem fairly active and appeared to be offering mostly consistent APIs (React, JSX) for a somewhat narrower but still large set of use cases for cross-platform application development. So at that point, I decided to freeze the searches and build out the rest of the choice around it, partly based on the React community's support of the libraries and tools (Redux, Webpack, etc.)

I do catch myself getting distracted here and there checking out other libraries and tools, and they might genuinely be superior in the context of an objective, head-to-head comparison. But having built up some familiarity and skills using the current choices, I can't justify the time and attention span lost switching to another set of libraries. Afterall, by then, something even better will have come along. :)

EDIT: I wanted to just add, "The fewer APIs I have to look up in the docs to use, the better" also has been a guiding principle as well. For example, I just use Webpack for build as well as bundling, as I don't want another API in the project for the builds (like Gulp, even though devs seems to like it).