[Comment removed by author]
Front-end development is a totally different ballgame, though. The reason for that is because everyone from every background is involved in it, bringing their own ideals and practices from their favorite language. Each of them saying “this is the right way and if you do it another way, you’re stupid.” It’s been going on for years.
You can either take a wait and see approach on new libraries, or you can try to jump on each new trend and complain about it when a new hotness comes out a week after you finished your v1.
So I have been polishing the rust off my C++…
I was stuck in an embedded environment for a while, where I only saw / could do pre-C++11 C++.
So part of me is going Wee! Grreat! Look at all the problems they have fixed!
Then reality hits….
Righto, I need an URI class here…. let me pull it in….
What!? Is this the ‘80s? Where’s the URI class in the standard library?
Perl, Python, Ruby, C#, Java… have had things like that since forever!
Oh you have to choose a 3rd party library and use that.
Wait, the 3rd party libraries I have chosen don’t even agree on the typedef for an ipv4 address!? WTF!?
This is part of why an ecosystem like Ruby or Perl or D succeeds..
They have the guts to say, yup it makes sense to abstract and standardised that concept and abstract away the interplatform crud… we will choose the best in class library available and bless it as part of The Standard.
And then the rest of the ecosystem stops arguing minutiae and gets on with the job of building great stuff on top of the standard.
The standards body is missing in action.
It allowed itself to be killed by commercial interests.
This whole response could have been one coherent paragraph.
You could probably have used a little less text.
Just get to the point…
There’s no real standards body on the current ecosystem of JS like there is in your example.
An example en which it was hard to read.
When you right comments in the
What you get.
I’m having trouble reconciling these two dialogues that I see online:
Since about forever:
I’m not saying these represent any community in any way, shape, or form. What I am seeing is the “always learning” meme being selectively applied, and this is just the latest incarnation of it: it’s somehow more reasonable to learn about endless yak-shaving (‘progress’) rather than the core concepts of computation (aka, what your job is).
This is what anti-intellectualism looks like, and it’s high time we call it what it is.
The things I’ve learned are important and everybody should learn them. The things I don’t want to learn are esoteric bullshit and people should stop wasting their time.
I don’t think it’s all yak-shaving, as they have some difficult problems, some of their own making.
The whole “x, but in JS!” thing, for instance, is mostly just yak-shaving. Bundling, minifying, and compiling JS (it hurts too much to say ‘transpiling’) are worthwhile IMO.
I don’t think what’s happening in JS is really a “requires constant learning” issue. There’s nothing really fundamental changing, it’s just the libraries people are using. You do need to learn things about a library, but it’s not really the same as learning a new fundamental concept.
With that said, I don’t fold all the newness and hot library bs of JS into the “learning” category.
Is it easier to learn a new library than a fundamental programming concept? Of course it is. I don’t think it’s anti-intellectualism, though. If people don’t want to learn new concepts, that’s on them.
Unless you have a decent amount of experience, every flavor-of-the-month library requires some work to use. Each library gains popularity by attacking the problem of managing state and UI changes over time in a different way. However, this difference in approach also means you have to think slightly differently about how to do what you need to do.
The only way out is to step off of industry’s treadmill of hype, buckle down, and work on understanding the tools in front of you well.
Being stuck in the industry treadmill of hype is more of a personal mental state, IMO.
Do you care about having experience in all of the new hot frameworks? Do you need to care?
I think the answers to those depend on your current employment status more than anything. New dev with no experience? You might want to get some in the new ones. Experienced dev with tons of experience? A cursory look should be fine.
WRT awful tooling and ever-changing state of the ecosystem, these seem to be entirely self inflicted problems. But I guess that’s what the debate is about, at a meta level. Did you need to write in ES2020 and then bundle up a bunch of transpiled polyfills, or could you have held your nose and written in yesteryear’s ES?
I mean, I just went through a eensy teensy itty bitty version of this. I replaced some code that used jquery to execute $.post() with var x = new XMLHttpRequest() etc. The “hard” part is that x.send() doesn’t form-encode hashes, but that’s literally a seven line function that’s trivial to write. I was using a 90K js library to get one seven line function???
var x = new XMLHttpRequest()
Now, on the bright side, dropping jquery (and jquery alone) into a project is trivial. So maybe a little wasteful, but I wasn’t wrestling with bundlerifiers or whatever. But at some point, if you’ve invested two weeks setting up your tooling just right, isn’t that two weeks you could have spent just writing code to do what you needed done?
Author would be more effective if instead of trying to deconstruct why the original author is wrong, instead tried to get at why the original author felt the way they did. Still, a decent counterpoint.
Hey look, sanity. How did that get into this discussion? I thought we had chased it all out.
I think you undervalue that pressure to “keep up.” It’s not necessarily just a personal shiny-chasing whim thing; if you’re going to deploy code in production to run a business, one of the key factors you have to consider is whether the sum of libraries and frameworks you’re using today are supportable in the (near to far) future. JS, almost uniquely, makes this decision essentially impossible to evaluate and fraught with incredible risk.
You can assert it’s a joyful Cambrian explosion of forward progress, but where’s the proof? Show me the place where the future direction of JS dev is less of a slow churning garbage fire (e.g., http://imgur.com/hjdsstB), and where anyone can put a stake in the quicksand and feel safe in their investment. You’ll struggle. That’s the problem.
The argument presented here seems to be that many tools gives you many choices, and that’s a good thing.
One of the biggest problems touched on in the original article (which this article is responding to) is the complexity of development workflow. There are multiple complicated, painful ecosystems around this. The current ecosystem originally grew out of the fact that we don’t have a module system in the browser but we do in Node. This forces people to use bundlers (or other hacks, like UMD) to pull code from Node into the browser.
That’s why I love Scala.js: