Modern JavaScript tooling is too complicated?
changelog.com
changelog.com
Not 1 year you can write the same kind of code (professionally), every month new libraries you have to use, always a new framework or cloud service on the horizon, always a new hype in the making. And if all the new things in the JS world would be great solutions it could be awesome (maybe). But the reality learns that it only gets more complex and tiresome every day. Juggling with design patterns, not because they are a better solution than the design pattern you were using before, no, it's because some famous JS artist came up with an 'idea' and the entire JS herd is following it blindly. Think you can still write in the old fashion? Nope, PR declined! You protest? Beware of the company politics, the herd always wins.
Oh btw, I guess the title is inappropriate, JS is deprecated, it's Typescript now! Not sure for how long, but the jobs where you can write JS are disappearing. So web developers are now forced to write in another language, with all it's brand new issues and pain points. Nice! Did I have problems with types in JS? Hardly, but that doesn't count, I now write about 20% more code to get the same result and regularly spend a few hours to get a basic line of code working because the TS compiler complains. It goes on and on, really, unbelievable.. Web development took all the love I had for programming away.. And I acknowledge it is a great recipe for burn-out, if you fancy that.
I originally came from C++ and recently went back to it after 8 years of web development. I totally unexpected rediscovered my joy for programming. I can code things again that actually work and are understandable, without all those black boxes of magic that are pure hell when something goes wrong. I gave up on it, it's not for me.. But still, I can imagine when you're young you can kind of enjoy the JS(TS) world with all those new and exiting things.
Edit: Parcel for module bundling and transpile, but I'm waiting for JS native modules. Eventually React too, will go away in favor of Web Components.
I remember a time when jQuery was considered so standard that every StackOverflow question about "How do I X in JS?" had as the top voted answer "Use $X() in jQuery". All that accumulated knowledge is now essentially a graveyard. I feel React too will be supplanted by something more closer to a WHATWG standard in the future.
The problem, as I see it, is front end developers are still expected to churn out features like they used to in large scale organizations, but we've matured as developers. It's no longer throw a .js file, a .css file and an .html file at a browser and woo hoo you have a site. It requires more time and bootstrapping, but the promise is code that breaks less often and is easier to maintain. It also means we have front end developers that are now specialists in different facets of frontend, such as builds, data layer, typing, feature development and framework design. Notice these are meta jobs.
In order to meet the demands put upon us by our former velocity, we often have to resign ourselves to blackbox libraries and such, which don't always contribute positively to one's stack. Just today we ditched a node module we'd been using because the owner refused to update it. We should be building more internally than we do.
Unless you’re a big company best to use what’s already out there if you can reasonably
The worst offender for me are reactive stores. I'm reviewing a simple candidates' programming assignment (in Angular, though). There is a simple taks to perform. The horrendously complicated and generally broken ones are those where the candidates decided to use a reactive store. Just tons of unnecessary code impossible to follow and decipher.
> every month new libraries you have to use, always a new framework or cloud service on the horizon, always a new hype in the making
Did your job actually make you switch frameworks or use new libraries every month? Or is this just a trope you're repeating. That's not a problem with JavaScript, but a problem with your management.
And BTW, there are three big frameworks that are all like 5 or 6 years old. React isn't exactly new.
> Think you can still write in the old fashion? Nope, PR declined!
I read posts every day where people talk about JavaScript's horrible language design. Now the language is expanding and solving a lot of those problems, all while maintaining full backwards compatibility, and you're complaining that it changes too often? The last major language update was in 2015, and everything else has been an annual gift of a couple of new features, all of which are developed with the input of the community, and you're still complaining?
The truth is, a lot of people are using JavaScript and it's very flexible, so, yeah, people come up with design patterns all the time. Some of them are good and stick. Some of them are not. But part of the fun of being a JS dev is you can choose to explore that or not.
> JS is deprecated, it's Typescript now!
TypeScript isn't my thing, but again, people are constantly complaining about JavaScript for not having classical language features like strong types. Then an alternative comes out, and is embraced by a large portion of the community, and again with the complaining! Just don't use it! And BTW it seems bizarre to complain about TS being too verbose when you are a C++ dev.
I'm not saying you can't enjoy C++ but your reasons for hating JavaScript just sound like repeated tropes. If you get better at the language (and this applies to TS too), it will stop being so opaque.
The market, if not your particular company, requires that you know the latest iterations/tooling of your chosen framework. Even if you're not forced to use the very latest versions, just being aware of all of that movement has cognitive overhead. If you choose not to pay much attention, you can quickly fall behind the curve. There is an inherent anxiety to that reality, whether it's legitimate or not.
Multiply the number of different tools in a given stack by the frequency of major updates to each, breaking changes between different tool/plugin versions, and you can start to grasp why people often complain about FE dev. These tropes are repeated for a reason.
I would argue that we should not be intentionally relying on technical design decisions to bust through difficulties which are more related to human factors and office politics than software architecture or implementation.
Typescript is a superset of JavaScript and your type issues could just be because you lack understanding of how type coercion works in JS. Additionally your tsconfig settings could be overly strict.
Huh, that's weird, because I've been writing in Angular & React and using the same basic libraries for years now. And before that it was jQuery and Handlebars and a lot of the same basic libraries for years.
I've made two large shifts in JS development over a decade.
Not sure why you seem to need to switch every month?
Of course this is not popular/cool, though.
As for being cool, my opinion is that shipping stuff is cool, and if your project is maintainable that's very cool no matter how you do it.
It's odd that we're coming up on 2020 and software projects checking their dependencies and overhead against their goals is still seen as a matter of fashion. KISS isn't sexy, and doesn't sell consultant hours. Those are features, not bugs, IMO.
I have a ton of worry about other devs, especially ones with no React experience walking into my code though.
With jquery it is totally reasonable to expect anyone who calls themselves a front end developer to have a working understanding of it. Can’t think of any other JS framework that can boast that.
They generally have the form:
document.addEventListener('DOMContentLoaded', function() {
var m = {
...model fields...
_observers: new Set(),
notify: function() {
this._observers.forEach(function(observer) {
observer();
}
}
};
var elem1 = document.getElementById('...');
elem1.addEventListener('...', function() {
...update fields on m...
m.notify();
});
m._observers.add(function() {
...update elem1 from m...
});
m.notify();
});Huh? Wrong decade I think. jQuery wasn't released until 2006.
Just, you know, have simpler problems?
SoC your stuff, solve the 80% instead of the 99%, challenge your assumptions about what you need and you'd be surprised how little complications you can get away with.
¹ one common tool in the pipeline actually being called babel never fails to amuse me.
I think a lot of these issues are symptomatic of front-end oriented toolkits trying to solve combined frontend and backend issues, causing oodles of arbitrary complexity.
It's hugely beneficial for some kinds of projects/teams, but so much of the challenge is simply due to domain impedence and using suboptimal tools for the job. Client-oriented solutions to server-client issues have some fundamental limitations.
Like, in vanilla JavaScript, you have a single global tree representing the state (the DOM), and you write event handlers that manipulate that tree. But that isn't a good fit for every use case, so you introduce React, which encapsulates all your functionality into components.
But that turns out not to be a good fit for every use case, so you add a state-management library like Redux on top. With Redux, you have a single global tree representing your state (the Redux store), and you write actions that manipulate it.
Congratulations, you are now back where you started, but you've introduced two third-party library dependencies (probably more, if your libraries need separate adapter libraries to work with one another) and a bunch of overhead and complexity.
See also: client-side navigation. "Pages on my website load slowly because the browser has to run all the JavaScript I wrote. How can I solve this? Oh I know, even more JavaScript!"
"State management" is a problem you think you have only because you're trying to use React for things it isn't good at.
For all the other cases, I don't see any reason to use one, and my experience of the same application developed, by different people, with and without a reactive store, tells me that the solutions without a store are generally much simpler and look way more maintainable.
If you 'encapsulate' every tiny bit of information inside GUI components you end up with things like storing a string in a GUI label or storing a list in a list selection component. Then every time you want to access that information you have to extract it from the GUI, possibly keeping in mind the lifetime of the UI components.
Now if you have a very rich client side desktop-like application, such as:
https://www.tradingview.com/chart
https://ahrefs.com/site-explorer
or if you are Facebook, then maybe a SPA is required.
(by the way, I picked those two examples because I'm pretty sure they do not use a SPA!)
Using jQuery will just make you suffer in the end. You end up having to write loads of code to manage the state of the DOM and it just gets more complicated as your project expands.
Or....Gradle...?
Modern JS is a dream to work with. The days of pre-transpilation and modularization with hundreds of script tags and giant IIFE's and worrying about cross-browser was a total mess. It finally feels like the web has matured as an application platform and I've been waiting for this day for a long time.
Now I have to figure out the difference between: ‘umd’, ‘commonjs’, ‘esnext’, ‘es2015’, ‘es2018’, and a whole bunch more.
I don’t want to keep up with JS politics just to be able to develop with the latest version.
Is using TypeScript, Webpack, React, and 20 other external libraries "too complicated" for a static marketing site? Probably. For a 200,000 LOC complex productivity tool? Probably not.
But most other languages only provides up to Grunt and Gulp equivalent, namely Gradle, Fake etc.
As who had maintained large Gulp scripts, those Scripts would eventually become a huge pile of non-standard and ad-hoc scripts.
Webpack is complicated, I admit. But it's much better than Gulp I my experience, so why is everyone complaining?
It turns out the problem Webpack or JavaScript solves are more complex than other language solves. JavaScript is the center of the Web, you cannot expect let CSS bundling itself, so do images and fonts. Let alone compression, prefixing, and giving fonts and stuff size thresholds to in-line them in JavaScript.
There would definitely better tools in the future like Parcel and Pika are trying but the problem doesn't go away.
I'm looking forward to see other languages facing the same issue in WASM age.
Sure, I could import all of corejs and call it a day. Everything would be polyfilled, but then I'd be wasting precious bytes and negatively impacting page load times. Some will even say the concern is no more than bikeshedding. But if you give little thought to bundle optimization, your carelessness will add up, and materially impact TTFB. It's a death by a thousand cuts.
My personal answer is no. Whether it's Stockholm Syndrome or not, you can conquer the complexities of shipping web applications written in modern JavaScript.
Becoming aware of the nuances has made me a stronger developer. Developing a deep understanding of polyfills, bundlers, transpilers, module formats (CJS, SystemJS, UMD, ES Module) and which browsers support which APIs has made led to me being more thoughtful in the code that I write. For people just looking to solve a business problem, without understanding the more tedious parts of JavaScript, it absolutely is too complicated for them. I empathize. But if you want to be a skilled front-end software engineer, it's in your interest to tackle these tools with some zeal.
I guess what we are saying is that there must be a better, not yet invented way to do frontend, without having to deal with this huge complexity that is unique to this specific field.
But everyone has different needs. So tools like Babel and Webpack allow you to pick-and-choose what polyfills and transpilations are necessary.
That might have been true once but its not anymore. Assuming you have node installed, its a one liner to get started in React[0] and Angular[1].
I've found that many of the criticisms of the modern JS stack come from outdated views about the ecosystem (no offense intended). I'd encourage you to give it another try (especially TypeScript) It's matured quite a bit.
"it’s 1v1v1 with Mikeal reppin’ team Yep, Divya on team Nope, and Feross sitting in the middle on team It Depends."
That is, the transcript, if it existed, is just 3 people reacting to the title.
We decided about a year ago. So I spend a year writing side projects in React and Redux. In the meantime, a new dev was hired to begin writing the React/Redux code. I just jumped into his code today and tried to add my own stuff, and I feel like I'm learning programming all over again, because it looks like absolute gibberish compared to the code I had been writing on the side.
So even if you are using React and Redux, you can write code that has virtually no resemblance to another repo.
It's insane.
export const createAction<T>(type: string, payload: T) => { return { type, payload }; };
// some component
onClick={event => dispatch(createAction<SomeInterface>(TYPE_CONSTANT, event.target.value))}
Where’s the boilerplate?
- there are too many ways to do something: it's hard to understand patterns (they change with every framework, for example), many different standards that aren't compatible with each other.
- javascript delays failure and fails silently: it makes software prone to bugs as well and it also makes the language hard to debug.
NodeJS, npm, yarn, millions of frameworks and libs just add complexity to the language.
My primary complaint would be that working in Javascript is absurdly difficult for the beginner. It's ridiculously hard to understand the fundamentals when they have been a moving target since the early 2000's.
The problem is that "best practices" changes every day, and from one employer or team to another.
- Structural, optional typing is good. Use it. TypeScript seems to have de facto "won", but just use something; the very act of thinking about input and output types tends towards better code and you always have the flexibility, within your module boundaries, to go outside the type system if need be.
- Structured, functional-or-mostly-so view libraries make your system less fragile. Use them. React, Vue, whatever. They discourage your developers from making tag soup; this is a good enough reason. (Yes, there are some people on the "vanilla JS" train, but there are reasons it's a minority group--it's harder, you run the very real risk of making a worse thing, and there's less out there to bail you out if you get yourself into a corner.)
- Do the work up front: lint aggressively, format consistently, run coverage tests, and so on. It's an investment in correct code, and get in the habit early.
What you use matters less in putting into effect good practices. Why you use it and what they do matter much more.
These days I write pretty exclusively NestJS serverside and React/React Native on clients, using TypeScript through the whole stack and Swagger-generated clients for plumbing, and it definitely no longer sucks. But I had to 1) have a reason to get into it, and 2) spend a ton of effort to weld together a consistent environment that values developer time.
There probably is too much nonsense going on at any one point in the JavaScript ecosystem. I mostly work in infrastructure/devops roles, where it's just expected that you know ten thousand little things that are arbitrary and stupid but will eventually bite you; having to hold an entire stack in my head and understand how to pivot and manipulate it is kind of what I do everyday, but it's not a standard programmer skill. If you don't have somebody who can do that--and it's a mixture of human communication and empathy, technical skill, and a certain kind of technical taste, so it's not as common as one might like--I still, today, see why somebody might say that JavaScript sucks.
Today it is very different. There is a huge chain of auto-wiring tools with very cryptic error messages. To just build a basic ES6 javascript webpack project with React I need over 800 libraries, many of which are automagically invoked via convention.
I literally have no idea what my build does, and hope my lucky underwear actually works today. Most of the time I am browsing through weird bug reports trying random snippets on the internet because there's no sane way to debug anything.
So the point is, explicit is a huge virtue. It is code you can trace and debug. Sure it adds a bit of time, but it is time up front that saves A LOT down stream. Meanwhile today's tools are built to save time up front and waste time downstream. You either follow the exact formula the original developers wanted or you're shit out of luck.
But we still act as though the very basic DOM functionality is some arcane art that has to be "fixed" by a library like jQuery, or as is more common now, an entire stack of large tools.
Having done paid work with React-stack apps, and personal projects with vanilla JS, I still see more advantage with less code on the vanilla side.
But there are simple tools out there for building your typical business applications. Stateful apps with NodeRun.com (https://noderun.com/docs/concepts/stateful-apps) make development similar to what VB used to be like back in the day (but for JavaScript). There is a Visual drag-and-drop designer for the UI and inherent database integration. I find that building normal database-driven apps is 10x easier compared to rolling your own HTML, CSS, React, Angular, Express, etc.