31–40 of 357 posts
This seems to suggest the rate of framework churn has rather settled down. Are JS devs finally starting to be satisfied with their current tools and not needing to restart every 18 months?
I apologize if the predictability of this comment, but I just want to say, I recently started a new gig at a company that has undergone a full on embrace of Javascript for tooling and server side projects and it boggles my mind how much productivity is wasted on this ecosystem. There is an interesting amount of energy put into making asynchronous code read synchronously in situations where asynchronous code provides…
I apologize if the predictability of this comment, but I just want to say, I recently started a new gig at a company that has undergone a full on embrace of Javascript for tooling and server side projects and it boggles my mind how much productivity is wasted on this ecosystem. There is an interesting amount of energy put into making asynchronous code read synchronously in situations where asynchronous code provides…
I really wish gar1t would make some new videos, I love them.
According to the survey, 213 people that took it have never head of plain javascript.
To be fair, a side effect of JS Fatigue is the inability to tell whether "Plain JavaScript" is the newest kid on the block or if it really means "good old JavaScript (ES3)". Especially when the headline is "JavaScript Flavors".
This seems to suggest the rate of framework churn has rather settled down. Are JS devs finally starting to be satisfied with their current tools and not needing to restart every 18 months?
It's not so much that churn has been greatly reduced, but that the worst churn has started to be centralised and hidden behind tools like `create-react-app`. There will still be more churn as people come up with ways to be more productive, however it will be hopefully concentrated in areas other than build process tooling.
Specifically the fact that we still don't have modules or widely-deployed http2 is what makes the build tool complexity necessary.
I apologize if the predictability of this comment, but I just want to say, I recently started a new gig at a company that has undergone a full on embrace of Javascript for tooling and server side projects and it boggles my mind how much productivity is wasted on this ecosystem. There is an interesting amount of energy put into making asynchronous code read synchronously in situations where asynchronous code provides…
I apologize if the predictability of this comment, but I just want to say, I recently started a new gig at a company that has undergone a full on embrace of Javascript for tooling and server side projects and it boggles my mind how much productivity is wasted on this ecosystem. There is an interesting amount of energy put into making asynchronous code read synchronously in situations where asynchronous code provides…
Could it be that you are still just new to it (in the grand scheme of things)? Because all of those things sound very similar to the complaints I hear from web developers on their first foray into desktop development. There are so many tools it's impossible to know them all (or to even know which one is best to use in which situation), so much legacy code out there it's tough to learn what the "right" way to do thing…
I apologize if the predictability of this comment, but I just want to say, I recently started a new gig at a company that has undergone a full on embrace of Javascript for tooling and server side projects and it boggles my mind how much productivity is wasted on this ecosystem. There is an interesting amount of energy put into making asynchronous code read synchronously in situations where asynchronous code provides…
Could it be that you are still just new to it (in the grand scheme of things)? Because all of those things sound very similar to the complaints I hear from web developers on their first foray into desktop development. There are so many tools it's impossible to know them all (or to even know which one is best to use in which situation), so much legacy code out there it's tough to learn what the "right" way to do thing…
I guess part of my point is I'm made uncomfortable by the encroachment of Javascript into areas where it's not particularly well suited, and the historical baggage it must carry into those areas. It's the when you have Javascript as a hammer, everything looks like a nail issue. I don't think my organization is unique in its embrace of Javascript-everything, either.
According to the survey, 213 people that took it have never head of plain javascript.
One possible explanation is they are not sure about what that means.
As an example, to me that sounds like the Javascript used in the browser. Is that the same as the Javascript I get from NodeJS? Which is "plain javascript"?
I think it represents semantic confusion and not experience. But that is just a guess.
I apologize if the predictability of this comment, but I just want to say, I recently started a new gig at a company that has undergone a full on embrace of Javascript for tooling and server side projects and it boggles my mind how much productivity is wasted on this ecosystem. There is an interesting amount of energy put into making asynchronous code read synchronously in situations where asynchronous code provides…
Could it be that you are still just new to it (in the grand scheme of things)? Because all of those things sound very similar to the complaints I hear from web developers on their first foray into desktop development. There are so many tools it's impossible to know them all (or to even know which one is best to use in which situation), so much legacy code out there it's tough to learn what the "right" way to do thing…
When I started writing apps using Cocoa, for example, I had a pretty good experience. Yeah, I fought some of the tooling that I wasn't really used to, but given that it was quite different from my backgrounds in web and embedded development, I was overall quite pleased with how easy and more importantly how obvious everything was. I found this to be the same when I wrote applications in Qt, and also when starting to work with newer languages (like Go).
This contrasts very much with the Javascript ecosystem. Despite having been a nominal web developer for approaching a decade, I am still consistently baffled by how difficult it is to get to grips with how everything is put together. There seem to be dozens of different workflows, none of which are entirely compatible with one another. There are bad configuration formats all over. Every tool seems to be broken into 200 different parts that subsequently have to be reassembled in order to implement a working pipeline. Documentation is erratic at best, and so on.
I used to feel pretty productive with Javascript, back when the web was a bit more 'Wild West'. But as it has developed as an application platform, it feels more and more like I am fighting the tools, rather than having them help me. That's not a nice feeling.