5 ms·

I 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.

I 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/0y4wx08838bdbcf954b1398c28f7020a3a523 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.

savanaly 8y ago
>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!
- lewisjoe 8y ago
  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.
tuesdayrain 8y ago
Es5 only? Jeez that would be an immediate dealbreaker for me with any potential employers.
- lewisjoe 8y ago
  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.
  - IggleSniggle 8y ago
    This is interesting. Today, when people say ES6, I feel like they actually mean esnext, as once you accept a transpile step from TypeScript or Babel, you might as well get the benefits of new language features in your codebase. I wonder how many people mean es2018 when they say es6, complete with some pretty dramatic code style shifts, including a tendency towards classes, async/await, and composition-first nameless but concise arrow functions. There are some coding styles that are popular in esnext that just aren’t practical in es5 because they would be too verbose and not “read” very well.
    - jacobolus 8y ago
      > just aren’t practical in es5 because they would be too verbose This is why coffeescript was a godsend. It produced very efficient code too, simpler and faster at runtime than the ES6 replacements.
    - WorldMaker 8y ago
      Relatedly, I'm increasingly surprised how many people still think they need a transpiler for ES2015-ES2018. Browser adoption for them has been much faster than the once problematic ES3 to ES5 upgrade. Especially for those that use the common suggestion for Babel of "last 2 versions of major browsers" presets, the amount of transpiled code has gotten extremely small, and increasingly so. For example: Arrow functions: https://caniuse.com/#feat=arrow-functions https://caniuse.com/#feat=arrow-functions ES2015 classes: https://caniuse.com/#feat=es6-class https://caniuse.com/#feat=es6-class Async/await: https://caniuse.com/#feat=async-functions https://caniuse.com/#feat=async-functions ES2015 modules: https://caniuse.com/#feat=es6-module https://caniuse.com/#feat=es6-module «There are some coding styles that are popular in esnext that just aren’t practical in es5 because they would be too verbose and not “read” very well.» I like to check my code after downleveling in Typescript to ES5 from time to time. There isn't anything in ES2015-ES2018 that downlevels to "unreadable" in Typescript. The "worst" you get is async/await transpiles to ES2015 generators of promises (function*) which then transpiles to ES5 switch/case state machines, but even with all of that downlevel work I think you'd be surprised at how readable it stays.
perfunctory 8y ago
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.
- lewisjoe 8y ago
  There's nothing wrong with handwritten scripts. The lack of problems are exactly why the current dev workflow has scaled and I'm saying this as of 2019, which I find interesting! The problem is opportunity cost. The rest of the tools in the market (Webpack, Rollup) are offering heavier benefits like automatic code splitting, dead code elimination and such things.
- gedy 8y ago
  Maintenance. Because seems they are usually written/owned/optimized by some build brainiac that becomes a bottleneck or leaves at some point.
  - TeMPOraL 8y ago
    The equivalent "modern" workflow is written, owned and optimized by build brainiacs with turnover on the order of weeks. I'd say that maintenance of "crude shell scripts" is much less difficult and expensive than keeping up with the latest webdev "standard practice".
    - untog 8y ago
      You'd be wrong. I'm not arguing that Webpack is a deeply confusing system, but there are tens of thousands of people out there figuring it out too. Almost any question has an answer a Google search away. Your bespoke bash script has no such community.
      - TeMPOraL 8y ago
sam0x17 8y ago
At Blockvue we have also had a lot of success going back to basics with vanilla js. Doing a large SPA in vanilla js is actually a charm these days and the result is extremely lightweight and fast. The SPA concept is sort of new, but if you really commit to not doing any server side page generation the result is so easy to manage. This also allows us to focus on having a fast crystal-based API backend to power our SPA and other services. We use a script to minify and deploy directly to s3/cloudfront, and then use lambda and some microservices for API endpoints. The turning point for me on this issue was when I realized that Google has been indexing dynamic js content since 2012 (I had no idea).
- mattmanser 8y ago
  I'm still firmly of the opinion that nobody wants a SPA apart from the developers of that app. I'd bet any of us could find a ton of weird and unintuitive things your app does, as well as it probably being slow to load, hard to use and brittle, in that you'll regularly put out an update that inexplicably breaks something for a day or two. Add on top that massive extra expense of doing a pure SPA compared to the ease and simplicity of developing a mixed server/front side app, I have no idea why anyone sane ever signs off on a SPA. And that's before we even get onto the vastly better tooling and development environments that server-side languages have.
  - sam0x17 8y ago
    It could be that our app is uniquely situated to avoid these issues, but we have had the opposite experience. Our API is versioned so things never get out of sync, the frontend code has no external dependencies so its as unbrittle as one could imagine, and we use aws API gateway to fake server side endpoints, so we dont have to do some weird url scheme. This could never work with a CRM though.
  - c-smile 8y ago
    I've architected Web Application that runs as in a) connected as in b) occasionally disconnected mode (LocalStorage + sync when online). For #b SPA is the only option.

savanaly 8y ago

>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!

lewisjoe 8y ago
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.

tuesdayrain 8y ago

Es5 only? Jeez that would be an immediate dealbreaker for me with any potential employers.

lewisjoe 8y ago
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.
- IggleSniggle 8y ago
  This is interesting. Today, when people say ES6, I feel like they actually mean esnext, as once you accept a transpile step from TypeScript or Babel, you might as well get the benefits of new language features in your codebase. I wonder how many people mean es2018 when they say es6, complete with some pretty dramatic code style shifts, including a tendency towards classes, async/await, and composition-first nameless but concise arrow functions. There are some coding styles that are popular in esnext that just aren’t practical in es5 because they would be too verbose and not “read” very well.
  - jacobolus 8y ago
    > just aren’t practical in es5 because they would be too verbose This is why coffeescript was a godsend. It produced very efficient code too, simpler and faster at runtime than the ES6 replacements.
  - WorldMaker 8y ago
    Relatedly, I'm increasingly surprised how many people still think they need a transpiler for ES2015-ES2018. Browser adoption for them has been much faster than the once problematic ES3 to ES5 upgrade. Especially for those that use the common suggestion for Babel of "last 2 versions of major browsers" presets, the amount of transpiled code has gotten extremely small, and increasingly so. For example: Arrow functions: https://caniuse.com/#feat=arrow-functions https://caniuse.com/#feat=arrow-functions ES2015 classes: https://caniuse.com/#feat=es6-class https://caniuse.com/#feat=es6-class Async/await: https://caniuse.com/#feat=async-functions https://caniuse.com/#feat=async-functions ES2015 modules: https://caniuse.com/#feat=es6-module https://caniuse.com/#feat=es6-module «There are some coding styles that are popular in esnext that just aren’t practical in es5 because they would be too verbose and not “read” very well.» I like to check my code after downleveling in Typescript to ES5 from time to time. There isn't anything in ES2015-ES2018 that downlevels to "unreadable" in Typescript. The "worst" you get is async/await transpiles to ES2015 generators of promises (function*) which then transpiles to ES5 switch/case state machines, but even with all of that downlevel work I think you'd be surprised at how readable it stays.

perfunctory 8y ago

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.

lewisjoe 8y ago
There's nothing wrong with handwritten scripts. The lack of problems are exactly why the current dev workflow has scaled and I'm saying this as of 2019, which I find interesting! The problem is opportunity cost. The rest of the tools in the market (Webpack, Rollup) are offering heavier benefits like automatic code splitting, dead code elimination and such things.
gedy 8y ago
Maintenance. Because seems they are usually written/owned/optimized by some build brainiac that becomes a bottleneck or leaves at some point.
- TeMPOraL 8y ago
  The equivalent "modern" workflow is written, owned and optimized by build brainiacs with turnover on the order of weeks. I'd say that maintenance of "crude shell scripts" is much less difficult and expensive than keeping up with the latest webdev "standard practice".
  - untog 8y ago
    You'd be wrong. I'm not arguing that Webpack is a deeply confusing system, but there are tens of thousands of people out there figuring it out too. Almost any question has an answer a Google search away. Your bespoke bash script has no such community.
    - TeMPOraL 8y ago

sam0x17 8y ago

At Blockvue we have also had a lot of success going back to basics with vanilla js. Doing a large SPA in vanilla js is actually a charm these days and the result is extremely lightweight and fast. The SPA concept is sort of new, but if you really commit to not doing any server side page generation the result is so easy to manage. This also allows us to focus on having a fast crystal-based API backend to power our SPA and other services. We use a script to minify and deploy directly to s3/cloudfront, and then use lambda and some microservices for API endpoints. The turning point for me on this issue was when I realized that Google has been indexing dynamic js content since 2012 (I had no idea).

mattmanser 8y ago
I'm still firmly of the opinion that nobody wants a SPA apart from the developers of that app. I'd bet any of us could find a ton of weird and unintuitive things your app does, as well as it probably being slow to load, hard to use and brittle, in that you'll regularly put out an update that inexplicably breaks something for a day or two. Add on top that massive extra expense of doing a pure SPA compared to the ease and simplicity of developing a mixed server/front side app, I have no idea why anyone sane ever signs off on a SPA. And that's before we even get onto the vastly better tooling and development environments that server-side languages have.
- sam0x17 8y ago
  It could be that our app is uniquely situated to avoid these issues, but we have had the opposite experience. Our API is versioned so things never get out of sync, the frontend code has no external dependencies so its as unbrittle as one could imagine, and we use aws API gateway to fake server side endpoints, so we dont have to do some weird url scheme. This could never work with a CRM though.
- c-smile 8y ago
  I've architected Web Application that runs as in a) connected as in b) occasionally disconnected mode (LocalStorage + sync when online). For #b SPA is the only option.