The melting pot of JavaScript (2017)
increment.com
The melting pot of JavaScript (2017)
1–10 of 200 posts
Re: The melting pot of JavaScript (2017)
#2I just wrote a proposal for my team today as to how the front-end tooling has changed recently and why we'd need to adopt them in our workflow.
https://writer.zoho.com/writer/open/0y4wx08838bdbcf954b1398c...
With confidential details masked, it's still a pretty good read for the rest of the Internet. Outlines why JS fatigue is not really bad but just improvements and what exactly is stopping us from adopting those improvements.
Resonates a lot with Dan's write-up. Excellent piece by Dan. A much needed one. I'd probably link this along in my proposal.
Note: We've built a pretty fat browser app with plain vanilla JS, strictly ES5 only, crude bash scripts for building a bundled js & all such ancient methods.
Re: The melting pot of JavaScript (2017)
#3Dan Abramov wrote a brilliant post here, IMO. So much here. Unix Philosophy, yes please. Considering the cognitive load of tool options and configuration knobs, and the impact of the JS ecosystem for beginners. "A tool should work with (almost) no configuration." Amen. "Mind your output" from tools (errors must be helpful and sort the important from the unimportant); I've felt this pain and have abandoned tools at the start because of incomprehensible errors. Love the idea of toolboxes w/r/t dependencies. Read the post for the details. Great work Dan!
Re: The melting pot of JavaScript (2017)
#4I just wrote a proposal for my team today as to how the front-end tooling has changed recently and why we'd need to adopt them in our workflow. https://writer.zoho.com/writer/open/0y4wx08838bdbcf954b1398c... With confidential details masked, it's still a pretty good read for the rest of the Internet. Outlines why JS fatigue is not really bad but just improvements and what exactly is stopping us from adopting those im…
>Note: We've built a pretty fat browser app with plain vanilla JS, strictly ES5 only, crude bash scripts for building a bundled js & all such ancient methods.
Jeez, man, I'm all for minimal tooling too. But ES6 is the lowest hanging fruit there is, I beg you to consider adding a transpile step to your build on your next project so you can use it!
Re: The melting pot of JavaScript (2017)
#5I just wrote a proposal for my team today as to how the front-end tooling has changed recently and why we'd need to adopt them in our workflow. https://writer.zoho.com/writer/open/0y4wx08838bdbcf954b1398c... With confidential details masked, it's still a pretty good read for the rest of the Internet. Outlines why JS fatigue is not really bad but just improvements and what exactly is stopping us from adopting those im…
>Note: We've built a pretty fat browser app with plain vanilla JS, strictly ES5 only, crude bash scripts for building a bundled js & all such ancient methods. Jeez, man, I'm all for minimal tooling too. But ES6 is the lowest hanging fruit there is, I beg you to consider adding a transpile step to your build on your next project so you can use it!
The problem though was Webpack was generating massive bundles (probably something to do with the polyfills needed for different browsers). We were able to achieve much smaller bundles by just sticking to ES5 features supported by the browsers we support.
Oh, and code splitting was out of the question. Most modules were attaching themselves to the global namespace (note: a large portion of the app was built even before requireJS was a thing). Which means code-splitting is a developer discipline category, not an automated one.
We have slowly started improving these things though. As I've mentioned in the document, the benefits are beginning to far outweigh the cost now, so yeah we'll move to ES6 soon.
Re: The melting pot of JavaScript (2017)
#6I welcome the slow transformation of Javascript into Ruby. Every single thing in there is already a thing in the Ruby ecosystem. Convention over configuration. The careful, but automatic dependency management. Principle of least surprise.
All things I didn't know how much I relied on until I moved to NodeJS and found them non-existent.
Re: The melting pot of JavaScript (2017)
#7I just wrote a proposal for my team today as to how the front-end tooling has changed recently and why we'd need to adopt them in our workflow. https://writer.zoho.com/writer/open/0y4wx08838bdbcf954b1398c... With confidential details masked, it's still a pretty good read for the rest of the Internet. Outlines why JS fatigue is not really bad but just improvements and what exactly is stopping us from adopting those im…
Es5 only? Jeez that would be an immediate dealbreaker for me with any potential employers.
Re: The melting pot of JavaScript (2017)
#8I just wrote a proposal for my team today as to how the front-end tooling has changed recently and why we'd need to adopt them in our workflow. https://writer.zoho.com/writer/open/0y4wx08838bdbcf954b1398c... With confidential details masked, it's still a pretty good read for the rest of the Internet. Outlines why JS fatigue is not really bad but just improvements and what exactly is stopping us from adopting those im…
Really curious what is actually wrong with "crude bash scripts for building"?
I had experience with both types of projects - the ones with home made crude build tools (in Python, not bash), and the ones with modern javascript build pipelines. The first build never broke. The second build would break every couple of months for no obvious reason without us touching the project structure.
Re: The melting pot of JavaScript (2017)
#9I welcome the slow transformation of Javascript into Ruby. Every single thing in there is already a thing in the Ruby ecosystem. Convention over configuration. The careful, but automatic dependency management. Principle of least surprise. All things I didn't know how much I relied on until I moved to NodeJS and found them non-existent.
What you said could be true of Java or any other modern server languagae.
Re: The melting pot of JavaScript (2017)
#10I just wrote a proposal for my team today as to how the front-end tooling has changed recently and why we'd need to adopt them in our workflow. https://writer.zoho.com/writer/open/0y4wx08838bdbcf954b1398c... With confidential details masked, it's still a pretty good read for the rest of the Internet. Outlines why JS fatigue is not really bad but just improvements and what exactly is stopping us from adopting those im…
Es5 only? Jeez that would be an immediate dealbreaker for me with any potential employers.
Well, for those of us from the 2000s era of web dev ES5 wasn't such a deal breaker. It isn't very concise, but ES5 isn't so bad either.
ES5 to ES6 isn't what Java is to Python. It's more like what Python 2 is to Python 3.