Trying to understand why
I’ve wrested with this idea for years, trying to come up with some semblance for how folks are funneled to this conclusion. Keep in mind this is an opinion piece, but I’ve noticed a trend. Most of the time frustration for users stems not from the language itself or it’s capability, but rather the poor user experience first time users encounter. Specifically when migrating from other platforms, and especially over the last few years.
How did this happen?
If you go back around five to ten years ago you’ll plenty of comments about about the state of the language, and it’s pitfalls at the time. Issues with speed, the syntax being difficult to learn, and having few options for structuring large scale applications in a standardized fashion.
Remember also the types of products being produced for the web at this time. Most developers were starting to form the online presence for their company. Including mostly static websites with some dynamic conten, usually utilizing a basic CMS (powered by PHP, Wordpress, or similar). Sure, fully featured web applications existed, but were still relatively new to the space.
Fast forward to today. Every tech company from startups to large enterprise companies live and breath on the web. It is abnormal not to have some sort of a online login to manage your product — or perhaps the entire product itself is made up of a web application. All signs point to this continuing to be the need and requirement for the web platform today and going forward.
What has spurred this transition?
This where things get a little complicated. What we’ve witness over the last few years is an influx of ideas from a vast array of minds trying to develop opinionated solutions to the problems and desires of “the modern web”.
This has clearly not been a painless process. In fact, the growing pains have been fairly widespread. Which in turn has resulted in one of the biggest problems of the platform — that being, the barrier of entry being a vertical wall, than a curve. There are so many ideas (some good, some bad) all trying to define the “best” way to solve a complex set of problems for an expanding system. Which has resulting in the misplaced notion that you must learn every single one to keep up and compete.
This is a major problem for new users. There’s almost never a singular answer for what new users should learn and use to solve a problem. Instead they get opinions thrown at them as if they were fact. With many people making recommendations based on their preference and personal bias, rather than quantifiable data.
Choice paralysis can also strike when there’s so many options available. How do you decide what’s best for you? How do you even discover and learn what‘s options exist? Much less find time to learn them all. This can be a foreign concept from someone coming from another language that has clearly defined answers to common tasks.
A state of constant change
Another major complaint I hear lobbed at the web world is things change too rapidly, new options are introduced too fast, and it’s “impossible” to keep up.
Again, this is coming from folks that are used to using the same framework or tooling standardized for upwards of 10+ years. Something web developers may envy, but a luxury obviously not available to a platform changing so drastically over such a short amount of time.
Not only are the requirements for the web shifting quickly towards mobile and web apps but the release of the recent ECMAScript 6 spec further confounded this.
Anyone that’s spent time in this space knows there’s a considerable amount of politics of the “when and how” specs are implemented by browser vendors. Not to mention these changes are not always immediately mirrored from desktop to mobile, even for the same vendor. This again causes yet a pain point when it’s not easy to determine what works in each browser/device.
However, this presents it’s own set of problems — first off, explaining to new users what Typescript is, and explaining it’s benefits. Especially when all new users may see initially is a requirement to learn two “versions” of the same language and add additional tools and steps for an already complex process.
How do we address this?
My personal proposal is a free, open source guide that presents a roadmap for learning the language and the ecosystem in bite-sized chunks. Here’s an example of how that might look:
- Explain the improvement coming from ES6, and how to use it today (Typescript/Babel)
- “Quality of life” libraries (underscore, lodash, jQuery)
- Package managers for managing and third party dependencies (Bower/NPM)
- Introduction to build tools for automation (Gulp/Grunt)
- Structuring large scale applications and modules (Angular/React+Flux/Ember, Vue, etc.)
You get the idea. The order above is no set in stone obviously. Keeping in mind that each step might take a considerable amount of time to learn, much less master. This should absolutely be echoed to the users.
Laying down a clearly defined path that starts with the core of JS and web development, then expands over time with solutions that will improve structure and productivity, and explains the benefits over time.
The guide could attempt to clearly define a few of the most popular options available for each part of the process, going into detail about their general advantages, and doing so (as much as possible) in an unbiased fashion.
What comes next?
We would need to keep in mind the level of effort and knowledge the person or team responsible would be required to put forth to build and maintain such a guide. Especially when things are still in such flux. New tech might come and go, and curbing bias would be a real challenge. So perhaps as an alternative would be a set of opinionated guides. With options tailored to different user needs and branching paths in place of a one size fits all approach.