JavaScript Fatigue or My History with Web Development
alexkras.com
alexkras.com
In other environments (e.g. Python, Java) nobody expects you to know everything about the specific libraries used in a company; once you know the language and a bit about the technologies (e.g. work on Linux, on a webapp or a desktop app), you're good, you'll pickup the details while working.
Forcing a technology change because it's not the "latest and greatest big, shiny thing"... I find this is a slightly disturbing trend in frontend development.
You would think creating, say, a form with a button and a textarea, and getting references to those things would be simple, but it's crazy painful in vanilla JS.
The reason one picks up a new JavaScript technology is because it is a better and smarter way of working.
Wave after wave of innovation is bringing better and smarter ways of doing things.
There seems to be some sort of vague idea that JavaScript programmers are following new libraries and frameworks like there is a Solid Gold Hit Parade of JavaScript and they all jump onto the number #1, and next month there is a new #1 so everybody changes to that simply because it is the new #1. That would be stupid.
I use ReactJS because it is a great way to program and gives and application an excellent and functional structure. I use ES2015 and ES7 because they make JavaScript very much more powerful than ES5. If something radically better comes along then damn right I'll switch to it if I can, because "better" means smarter, easier, faster, more powerful - some combination of those to a greater or lesser extent.
The JavaScript community desperately needs a fresh wave of innovation - but this wave must be about simplification - ideally the almost complete removal of all the pain associated with configuration of JavaScript build tools, which right now is excruciatingly and unnecessarily complex and painful - create-react-app has started this process and sets the standard for other tools moving ahead - the right amount of configuration is zero.
It is necessary to use a bunch of painful JavaScript configuration and build tools in order to get your stuff to run. Waves of better, simpler and smarter build tools overrun the previous generation because they have found simpler and easier and more powerful ways to work.
Lets just drop the idea that JavaScript programmers are a bunch of airheads who follow the latest trends whilst they pull on their flared pants and fancy hairstyles.
- why can't old libraries/frameworks/things evolve, instead of forcing a breaking change? In many other languages evolution seems to preferred to revolution; in JS, evolution seems to be the norm.
- Is that "better and smarter way of working" THAT MUCH BETTER AND SMARTER? When working JS, it seems that a complete overhaul of an application (or of an ecosystem) is required every very few years. Ultimately, software development should lead to business value; does the improvement in generated business value justify the costs associated with such a tech twirl?
Absolutely yes. ReactJS is an application architecture that is a complete rethink of how to structure client side applications, and it is an architecture that is being applied outside JS and the browser because it is so much better. The fundamental concept of one way data flow from parent to child through the application requires a start from scratch approach, and would be severely compromised were it to be implemented as an "additional" evolution of some existing application framework such as AngularJS. Yes - that much better and smarter.
ES2015/ES7 are radically better languages that make hugely important changes to JavaScript. Yes - that much better and smarter.
Transpilers make it possible to run ES2015/ES7 even on browsers that support only ES5 - that is amazing - yes - that much better and smarter.
Build tools such as minifiers and packers and uglifiers perform magic to shrink and optimise code for a range of benefits including end users performance - Yes - that much better and smarter than sending a chunk of raw JS to the browser.
In short, yes, JavaScript is experiencing a continuous wave of really major and significant improvements that justify ditching the previous generation entirely.
I will say however that breaking changes give me the shits abut for the most part I am willing to endure them - I simply must assume that the changes are for the better because I don't have time to really understand every single change in every library that goes into my application - no JavaScript developer does - nor indeed does any Python developer try to understand every change to all the Python libs that they use.
Scala, Purescript, Haskell, Elm, ...
1. By far, has the largest ecosystem.
2. If you use a linter, a typechecker (TS or flow), and transpile your code (TS or babel or both), JavaScript is actually a pretty nice language to work in.
Sure it's a chore to set up all the initial tooling, and learn the ins and outs. However, once you're past that, it's usually not worth it to switch.
2. It's still far from the state of the art in PL design and missing:
* Nice static typing with type inference
* Nice guarantees about null access
* Nice guarantees about interop between client and server
* ...
>However, once you're past that, it's usually not worth it to switch.
That is somewhat circular and can be said of virtually anything. That is, for every minute you invest in a tech, the degree to which it is worthwhile to switch to another tech diminishes. I'm speaking primarily about tech like frameworks that is aimed at making us more productive.
The exception might be a truly revolutionary new tech that sharply boosts productivity, but also has a very low learning curve. However, that scenario seems particularly unicorn-ish where JS frameworks are concerned.
But especially when you are working with other developers and a mixture of skill levels, impedance mismatches are useful paper-cuts to try to minimize.
I agree, it's not a strong argument, but it is an applicable argument to the discussion. There are trade-offs in every decision, and this is a consideration in those trade-offs.
Look at Android for comparison:
- ReactJS: React Native, also any overall architecture like MVVM or MVP.
- ES2015/ES7: JDK 7/8
- Transpilers: Kotlin
- Minifiers/packers: proguard and others
- Gulp and co.: gradle
- Other libraries: android has a number of libraries to handle network requests, image loading, animations etc.
What I'm trying to put across is that JS has transitioned from a language that would show and hide elements of the DOM to a serious language used everywhere.
A good developer takes the time to understand the tooling around their platform and language.
I have just inherited a project written in 100% ES5 and I had forgotten how obscenely verbose JS <= ES5 really was. Every extra line of code is a liability and will slow down app development. Language features support precision and conciseness and that in turn promotes enterprise-level development. A toy language (old JS) can never support a full in-browser application.
With javascript, as far as a I can tell, "change in a library" means you do indeed throw out the library and adopt a new one, then write your entire code again from scratch and repeat the cycle next year. To me, that sounds like madness and just makes me happy I don't have to deal with all this.
Reality is very different from these discussions.
You can with a 10 line HTML file and linking a few CDNs make an interactive application that can reach 1 billion people with no install and no buffer overflows. That's magic. The 90s wish they could do that.
10 ShinyNewJSFramework = 1
20 Use framework
30 Do conference speech about how much better it is than JQuery
40 Hit problem X
50 Find ShinyNewJSFramework is nigh impossible to debug
60 Eventually come to loathe framework because of problem X
70 ShinyNewJSFramework += 1
80 GOTO 20I am intrigued and ponder the idea of there being "JS Standard Libs" and wonder which ones will initially get picked for the honor. I don't think it will be React or Angular but definitely "something" like them, even if it is a version of Web Components.
That'll also mark a huge change in performance and download metrics, because if your browser already has your framework built in, your delivered code base is suddenly a fraction of what it was. And then there will be more opportunities there, too - dynamically providing the framework where needed in a separate code split, vs. a browser that does not need it.
We're just at the beginning, really. Browsers stalled for 15 years and have shifted into a period of innovation again.
Segmentation fault. Core dumped.
$ ls
brain.coreI've specifically tried to avoid Choo/Vue/Whatever until there has been real traction in the job market and the community behind that framework. BUT the move from each 'framework' to the next has been a revelation in how to do things better.
I feel comfortable now that React is delivering an ecosystem that is going from strength to strength and has brought a maturity to the front-end javascript ecosystem that was missing. Huge props to the community for that.
It's not the JS world, it's the browsers world. I think a better comparison is iOS vs Android vs web development.
And standardization takes many years to reach mass adoptions. No language come close to such a mess. Even Python 2 to 3 migration wasn't as complex.
Yet, they move fast, faster than those languages that are controlled by one authority.
Frameworks are important because at the lower level, things are not as simple to get done as those language with only one authority.
They API agreed by the authorities will definitely be thin. So the community step up with frameworks.
Of those who want JavaScript experience, it's usually followed with "Do you have any .NET experience?"
Turns out that adapting to rapid change is a critical aspect to this career choice. It is also a problem for businesses, which you start to grapple with as you move up the chain of command. The mistake is wistfully hoping that things would slow down enough for you rest on your hard-won knowledge, as in other fields. There is no competitive advantage in aging technology.
Well maybe it isn't a field after all. Maybe it's "pop culture" like this cranky old guy says https://www.youtube.com/watch?v=FvmTSpJU-Xc.
Some of this comes down to personality, too. A lot of people talk about how people were abandoning ruby and rails once it was no longer the "new hotness". Plenty of us (who like rails) came to it somewhat reluctantly, only after the benefits were very clear and the initial chaos had started to subside. We, the reluctant ones, just tend to be a bit quieter about things. I think we're reluctant because we see greater danger and risk in a constantly evolving set of technologies, and we don't like spending a lot of time figuring out how to get a drop down list to populate, not when there's limited time and there's value to be added on the back end.
I've been at this for a while, and I'm getting more and more ok with sticking with an aging technology - even when I know the technology is becoming obsolete. Right now, it's pretty clear to me that web based UIs in the future will be more asynchronous and elaborate, but there will be a lot of false starts and dead ends as we get there. Remember spring mvc, spring di, iBatis, hibernate, tapestry, pico, tiles struts, struts 2...? Yes, the old request-response servlet with jdbc was unlikely to remain a choice for new development, but honestly, I think it might have been a good idea to stick with it for a while and stay out of that mess. Yeah, you'll need to change and adapt, but that doesn't mean you need to jump into the swirling mess.
...unless you do! There are, of course, remarkable opportunities when a new technology hits, and if you wait for it to settle down, you may often find that others have too great a lead. You just really need to figure out if that's you. Because otherwise, you may find that instead of improving the accuracy and speed of some critical calculations your users need to improve their supply chains, you instead spent all your time figuring out how to asynchronously update a drop down list depending on where they clicked on a map. And a round trip to the server and an extra second to load that drop down list might not have been all that big a deal compared to the actual business use of your app.
Well, except for employers
If they don't and still expect me to follow whatever their whim of the day is, then I'm glad I'm in an industry where I can safely say I'd need to look for another job then.
AKA clickbait.
This is just not true. I recently had a discussion at work where I was flat out asked "how do you expect to learn new things if you don't try new libraries?". Coming up with a solution yourself (assuming these libraries are even introduced to solve an existing problem, which is sadly not always true) was not seen as an acceptable answer...
The options appear to be assimilate into this culture, or find a new industry to call home. Front-end dev doesn't appear to be for people that care more about a lean, pragmatic stack than a trendy one.
Frankly these frameworks and libraries are all very similar and they do very similar things. Once you've learned one you can transition to the others quickly (it's the same way with old web frameworks, MVC frameworks are all the same with minor tweaks). They are worth evaluating though because some of them do one thing better than others, might as well borrow it where possible.
I love learning new technology because even if I don't end up using framework x or y, I can pick up the best parts and use it in my own work which becomes simpler and more expressive as a result. I don't want to keep building websites from 2005. There have been some real advances and it's fun touse the best parts.
Using other's tools is trading off knowledge for development time. It's often a good trade to make, but to pretend that learning the API surface of library #34341 is going to improve your skills more is wrong.
Most of these frameworks offer fairly simple APIs that are frankly pretty trivial to learn --- the key is to learn the application architecture and why it's different than the alternatives.
Anyway, I think we can agree that exposure to other people's thoughts, and also coming up with your own thoughts, is probably the most fruitful way to learn.
Scientists publish papers so other scientists don't have to run the same experiments over and over. We have HN, SO, and other developer communities for that purpose. Read, learn, watch, wait. "Try" at the point you think it sounds so perfect, you have to try it.
Sentiment analysis on issues/PRs would be nice there too.
That is, devs have become more assemblers than coders. I think this is due to the explosion in OSS, with all of the libs, frameworks, etc.
On balance, I believe it's made us more productive, but the time spent writing logic has gone down vs. the time spent learning, assembling, integrating, etc. So, devs are expected to keep up on all of the latest tech, tooling, etc.
Of course, the demands of agile development just pours gasoline on it.
You'd be surprised -- since even single stacks change all the time. Try using React Router and keeping it stable.
Heck, even React changes paradigms (from mixins and factories, to ES6 classes and pure components, to fibers, etc). And from pure React, to coming up with Flux, 4-6 flux alternatives, the Redux dominating, etc.
And let's not get started with things like Angular to Angular 2 et al...
If you read the conclusion, the author is actually very positive about the entire experience.
Coming up next, WebAssembly for strong obfuscation.
[1] https://auth0.com/blog/7-things-you-should-know-about-web-as...
I feel like if the front-end dev world is so keen on reinventing itself, it should just go all the way...repackaging HTML/CSS/JS in new and interesting forms and frameworks isn't getting anyone anywhere, IMO. Scorched earth, a new protocol for web applications...don't even call it the web anymore...just put on your CS hats and start over...kill the whole thing with fire.
Figuring which PHP framework to use was a problem of choosing between dozens of options, each with their own mighty cons. Every time a new framework came, it demonstrated an ability to fix all the known problems but time and again it faltered (Kohana, CakePHP, Yii). In the recent times, Laravel has provenly become a better choice than what was available only a few years back. It has grown a community of a considerable size and it's unlikely it would getting supplanted in future.
I am guessing at some point in the future, the landscape would stabilise and a single approach would become the obvious choice for JS just like Rails is for Ruby.
Python in 2007 was Django, web.py, Subway, Turbogears, Pylons, Werkzeug, Zope, and a bunch of tools a lot of people have never heard of competing for space. Who needed all of those frameworks anyway?
It took awhile but slowly what works and what doesn't was figured out and we've got better approaches. Web programming circa 2007 was by its nature simpler and despite that the Python community (which is a blip compared to the JS community today) churned out a lot of stuff.
You can still build websites like it is 1999 but you've got a lot of other options now, too. Use the best parts and dip your toes into that stream of new stuff when you feel like it. Competition and progress beat the hell out of stagnation though.
Problem is rather developers don't know how to organize their code without the help of the Framework. If they knew, Frameworks would not be needed, only libraries.
One Framework to rule them all will stifle progress, it locks the community into one size fit all mentality and therefore clouds the minds of the developers to not think about the possibilities outside their worldview.
Laravel will, of course, eventually be replaced, as with all frameworks. Current hype now are "micro" frameworks.
So all that effort put into the Framework will be partially lost due to it is locked to that Framework.
Lessons learned ought to be, write reusable framework independent libraries instead.
I've worked on windows applications and just hated it. All this code handling the state of controls depending on the input/action.
Sometimes I have the feeling I'm doing this stuff on the web again which I haven't for over 10 years and it just feels wrong.
The underlying model is incredibly simple. You have a visual model/datastore that you manipulate and the UI changes as a result. Interactions with the UI drive events which might call out to a server or do a calculation, which in turn changes the view model/datastore and that changes the UI and so on and so forth...
You probably get that, but I've down programming with wxPython, Qt, etc. I've done Django, Rails, Flask, etc. and frontend frameworks are so much more powerful and easier to use than those old models and getting them up and running takes a few minutes. When I see how much difficulty and how much anxiety this new tech is causing people it makes me wonder if the frameworks are just covering up how easy all this stuff is and how powerful it is.
It's really exciting stuff, it sucks if people are missing that.
But if you just want to get an api up quickly its really hard to beat Flask or even Bottle (not sexy but very simple) and I've never used it but Sinatra is supposed to be great, too. Microframeworks are great.
Oh yeah your OS and libc too have them, the computer itself has them. You don't need the things you don't need to not exists in order to make use of what you need.
Therefore, all the complexity of building interfaces will be in the libraries and because opinions on such complex issues vary, there are many libraries to do the same thing.
Eventually the interior ones are recognized and culled. They typically are supported for quite some time after becoming uncool, it's just that no one wants to work with lame, obsolete tehnology for good reasons.
The solution I see to this are compile-to-JS languages that make it possible to use a different ecosystem of libraries than te JS one, like Scala.js. However, those tools are also still evolving, so one way or another you're dealing with a lot of library churn in frontend development right now, so learn to pick winners and stick to them until it's as weird to use them as jquery for complex UI was in 2012.
For the longest time, js was just a thing I did on weekend or as part of tertiary projects at work. I first used js as a kid for my geocities page, used jquery and YUI for a work projects starting about eight years ago, experimented with Angular, and most recently embraced React and es6.
Almost two years ago, I quit my job and started building a side project in React and Fluxxor for fun. At this point there were a bunch of Flux implementations and no dominant library had emerged. I got frustrated with the build process and then got distracted with other life experiences.
I returned to javascript less than a year later and was amazed at how much better things got. I could do npm install and npm start and there was a good chance things would actually work. I was doing the same google searches but noticed that the documentation was a lot better. I also had a friend this time around and he steered me toward Redux and es6. Javascript suddenly became an enjoyable language for me enough that I plan to focus on it. This is after more than close to twenty years of fits and starts.
If you use simple, clean modular coding patterns, componentize for reuse, make judicious use of promises, and sprinkle in lightweight templating and routing libraries, etc., you'd effectively have your own mini-framework on which to continue building. After all, frameworks themselves are code under the covers--code that encourages patterns.
Sure, some say it's reinventing the wheel to write JS without someone else's framework. But, it seems to me that the frameworks are re-inventing the wheel. Not only is there a new one every day, but they are even re-inventing themselves (I'm looking at you Angular). Looking at the mere scaffolding alone for some of these frameworks makes me think, "what are we doing to ourselves?". Generate an "empty" project on some of these guys and prepare to be overwhelmed with opinionated cruft. Rolling my own code is not reinventing the wheel, because Angular, et. al. are not the wheels I'd invent in the first place.
Until a framework comes along that truly abstracts away HTML, CSS, the DOM and the rest of the old Web, so that it genuinely allows construction of clean event-driven, componentized applications, I'm not sure I see the benefit of playing the framework du jour game.
So react?
Projects can have three plus build tools that each take a long time. Massive list of dependencies plus bad dependency management, lack of documentation, everything changes so fast you need to find the correct stackoverflow answer for this week solution to your build problems, build tools depends on other build tools configurations in undocumented ways, reimplementation of the model & business logic of each project, constantly reinvention of the wheel.
And the end result? Web just becomes slower and slower.
Developers today build software that fits their paradigm, not the users experience.
Most of my recent web work has been trying to manage shared libs and duct taping the build process together. Every feature branch has major shrinkwrap merge conflicts because there is so much module churn.
By comparison Python's primary web framework in 2012 was Django, and today it remains Django. Despite this relatively glacial pace, there's been a ton of improvement to Django, and the surrounding Python ecosystem. A more conservative development culture can pay off sometimes, since it allows the community as a whole to focus on polishing the existing ecosystem. As opposed to dropping Django when "real time" Websockets were all the rage, there was a concerted effort to include it in the framework with the Django Channels project.
Admittedly though the community isn't perfect. There was quite a schism over Python 2 vs 3 for a while. Thankfully it's looking like that may be past us.
Anecdotally the Python community seems more active than ever.
The webapps that services those industries has changed massively in the past decade. The web has evolved from simple documents to complex applications. The browser is the new app delivery platform, and it's perfectly reasonable that this would bring increased complexity.
Backend development has countless languages, compilers, frameworks, toolchains, CLIs, OSes, containers, etc. - so it's really not that strange to see frontend dev catch up.
What's rather amazing is that there's just 1 language with everything else being frameworks and tools that let you shape it to your needs (and also runs just as well server-side with nodejs).
Large projects or team projects, you will want to use something with more structure.
I don't get all this tooling and framework hate - no one is forcing you to choose anything, it's an open buffet, and you can choose as much as you want from wherever you want, for free.
Not an invalid point. Mention jQuery here, or anywhere, and witness the response.
If you project calls for "standard, ECMAScript, and (gasp) jQuery," then use them! Just be aware of the benefits and trade-offs.
It's a fine balance, choosing between a technology you know and "always be learning". Experience guides how much of the bandwagon you jump onto.
The funny part is, that in no other industry is there this expectation that things be plain, simple and easy. We, as developers, are blinded by our desire for instant gratification that is uncommon in other industries.
My mom, as a paralegal, never complained that the path to completing a case took 47 different filings with each page printed in triplicate, whose versions changed depending on the dates in the case. It just.. IS. Sure it can be better. But the expectation that it be, in an almost petulant way, is what I'm talking about here.
Before, I wanted to use the latest stack, maybe looking for approval from the "community", something like: "Hey, I'm building a X app with Express, React, React Router, Redux, Immutable..." But by the time I had the basic setup, my motivation was gone (at that time there was no react-starter-app[2]).
So I'd say you should start with whatever you are most comfortable, doesn't matter if it's React or jQuery. The goal, IMO, is to start building stuff.
Now, I just don't care what's the latest JS framework, I don't dislike them, all the opposite, I get excited about them[3], but I focus on what's my best weapon for the job.
- [1] https://github.com/mzabriskie/axios
I'm sure there are some people with organized jQuery front ends, but it's way too easy to have a mismangled giant ball of mud. Going with a framework you can of course still have a giant ball of mud, but it's a lot harder to get there. Anything component based is a big step up in organization.
My other big issue is 90% of what I'm doing on the front end is ajax calls and keeping the UI state up to date. A framework like Vue makes it so trivial.
I sincerely encourage you to give something like Vue a try. You don't have to adopt it all in, you can use it for just a single on page component and see how you like it. The getting started guide is great - if you have a solid understanding of JS you will be up and running in an afternoon.
I was hesitant like you and as soon as I tried Vue I haven't looked back.
<script type="text/x-template" id="component-name-template"> <div> {{ msg }} </div> </script>
Then when setting up your component you specify the template property with the id, e.g.
Vue.component('component-name', { template: '#component-name-template' });
Honestly though this sucks if you plan on reusing components. Can I ask why you don't want a build step? The single file components are great.
Just didn't want a build step due to complexity. I know it's not that difficult, but wanting to keep it as simple as possible.
I don't really get why Vue opted not to support URLs for their templates. It could be easily managed via co-location of templates with components and/or naming conventions. You actually wouldn't even need to specify the URL. It just grabs it from the component's directory by name.
Anyway, for me, this is a weakness. I get that they want to maintain the single file component model, but I'm not sure it's worth it when your choices are literals, script templates, or an extra build step. OTOH, co-locating a dependent file is no biggie, even if you don't get to claim single file components.
EDIT: I was close to going with Vue for a project a month or so ago. But, wading into it, I realized the build step would be necessary to do it "right". Suddenly, you're downloading plugins, xcode, and all kinds of other stuff, then setting up a build. It just seems a lot for, essentially, single file templates. Granted, several steps are automated, and you're just issuing npm commands, etc. But, I started thinking, "do we really want all of this magic? What if the build just doesn't work one day or we need to reconfigure? Now we're troubleshooting and figuring out the linkages that were created and the other magic.
The whole process was a stark reminder that you're in someone else's world. Maybe I'm too big on control. But, I don't want to be sucked into too many dependencies.
That said, once I decided to roll with it, it took about a week* to get it configured how I have it now and have a decent understanding of how/why it was configured. *not a straight week of banging my head into webpack, but some bits of time here and there as I did development
The one other thing that kind of pushed me over the fence into going down the build step route was that I get a minifier, a LINTer and get to use ES2015 (or typescript, or whatever) syntax.
>"do we really want all of this magic? What if the build just doesn't work one day or we need to reconfigure? Now we're troubleshooting and figuring out the linkages that were created and the other magic.
Totally valid concern and I see where you're coming from. Once I got into it, though, I realized the only webpack specific syntax is the configuration; how you link your JS files together is just through import/export statements (ES2015 and beyond module system).
>it took about a week to get it configured
Funny, that's about what I thought it might take--a week of somewhat committed effort. Felt like we didn't have that to spare though, and wasn't 100% sure about the ROI on that time. Felt like a roll of the dice.
Now, whether we'd have already recouped that week is an open question, and setting up a structured JS project was also no small task. But, likewise, we now have a good pattern/mini-framework with a component inheritance model. So, we're recouping that investment as I write this., and we're not tied to deep dependencies or magic.
Next time out, I may have another look at Vue. But, I am really hoping for a more componentized-event driven model that completely abstracts the old Web. Even moreso than React, but with more simplicity and only JS or Typescript in the mix. Kind of a Swing for JS is the best analogy I can make.
Still, if you must: create classes to represent components, with methods used to manipulate markup, and plug those methods into a simple pub/sub event bus. This will work for very simple apps, but ask yourself - how simple will your app remain?
I haven't done webdev since 2010 and now that I look at it, it just seems so bizzare.
That should only take a few lines in a Makefile.
JSTARGETS = foo.js bar.js
build-js: $(JSTARGETS)
foo.js: foo_main.js lib_a.js lib_b.js
cat $< > $@
bar.js: bar_main.js lib_a.js lib_x.js lib_y.js
cat $< > $@
> output 6 images for all the sizes
IMAGES=( baz quux )
IMGSRC=(patsubst %,src/images/%.jpg,$(IMAGES))
IMGSML=(patsubst %,build/images/%-small.jpg,$(IMAGES))
build/images/%-small.jpg: src/images/%.jpg
convert $< -resize 25% $@
build-images: $(IMGSML)And the moment you accept that it is necessary (and why wouldn't it be - languages are for developers, not computers, and that means they by necessity will include cruft), you require a build system to at the very least, run the optimizer and minimizer.
It seems like a trivial problem but it isn't. We are long past the days when JS was only used to make an image blink.
It no longer does. The tools move on because the uses get more complex. See the sibling reply here for a good reason why.
[1]: https://github.com/tdewolff/minify/tree/master/cmd/minify
Offtopic, but when does one start to be "senior" then? I've been coding for the past 17 years or so, including about 6 years professionally. Do I get to be a "senior" dev now? How do I convince my boss?
It differs massively from company to company. Where I'm currently working the guideline is 10 years relevant professional experience plus either significant project management experience or having an area where you can generally be considered an expert in your field.
I've also worked at places where people 3 years out of school are considered senior.
I also credit them with promoting modern web development and producing a realistic expectation that browsers can actually present some really cool, sophisticated applications. It is largely because of Angular 1 (and other, less known libraries) that we currently are seeing an explosion of innovation. I may not have liked the framework, but I cannot deny the incredibly powerful (and in my estimation, positive) effect it had on the industry.
Anyway, what are you currently using? Why?
Or you can even take it further and go focus on more networking / sysadmin / devops area. Les fatigue there.
I've recently moved from ASP.NET MVC/jQuery to Angular4. I'm extremely happy with the transition and I intend to stick with Angular. After not worked with React (yet), what am I missing?
I have "JS Fatigue" fatigue