Live data from Hacker News

The Controversial State of JavaScript Tooling

ponyfoo.com

71–80 of 160 posts

Re: The Controversial State of JavaScript Tooling

#71

> People take libraries like lodash – or jQuery, as we analyzed earlier – and insert the whole thing into their codebases. If a simple bundler plugin could deal with getting rid of everything in lodash they aren’t using, footprint is one less thing we’d have to worry about. If you use Google CDN, why does it matter how big jQuery is? If N people use their own "smaller" M-byte copy of jQuery, browsers will have to dow…

what everybody else is missing:

browser still has to parse & execute the javascript, which is half of the startup time, and if you are fully a SPA without server-side rendered markup, this increases your time-to-glass by about double on web clients

Re: The Controversial State of JavaScript Tooling

#72
Solution: The facade pattern.

Tl;dr: Y'all need better API designers.

JS modules are still bleeding edge but they're a necessary requirement to put the facade pattern to work.

Each library should ideally be separated into multiple modules internally.

The main source file imports all submodules by default making it easy to get started.

  import 'rxjs';
As a project matures and it comes time to optimize dependencies for performance, the main import can be swapped with feature-specific imports to trim the fat.

  import { Observable } from 'rxjs/core';
  import { FlatMap, Debounce} from 'rxjs/operators';
Optionally, an additional facade layer can be included to import specific classes of submodules.

  import 'rxjs/operators';
Or, alternatively:

  import { OPERATORS } from 'rxjs';
A facade is nothing but a js file that contains a bunch of imports that are logically mapped to one or more exports.

The 'real' issue is, it wasn't really possible to use this before the ES6 module standard because of the divergence of implementation-specific features of the existing module pseudo-standards (ie AMD, UMD, CommonJS) and the overreliance on bundling required by the expensive overhead of HTTPv1.

JS has a lot of baggage and it's going to be a while before the community as a whole learns how to design non-sucky APIs.

If you want to see this in action, take a look at http://github.com/evanplaice/ng2-resume. In it, I use facades extensively at multiple layers to compose smaller components/directives into larger ones. It maximizes reuse while allowing a great degree of flexibility.

I still have freedom to break off chunks of the source for reuse elsewhere. For example, I'm planning to move the models to a separate repo for use on the server-side. It's trivial to bring those chunks back in via the ES6 module loader and a package management utility like JSPM/Webpack.

Re: The Controversial State of JavaScript Tooling

#73
post #19

Are there any documented cases of a business failing because their JS payload was too large? I get that smaller code is easier to understand/work with, but I've never been able to internalize the desire for small payload -- just doesn't seem like it ever matters outside of philosophic reasons for saving user's bandwidth (especially if it comes with a steep tooling cost). It strikes me as a technical pursuit in search…

I think there are circumstances where it is very valuable - it depends on your target audience. For example on mobile, connection speeds in major cities in developed countries maybe rocketing, but substantial areas still need to make a lot happen with very little bandwidth. So it can be a small competitive advantage.

See my reply to your sibling comment. You can measure very real changes in SEO, user engagement, bounce rate, conversion rate and sales on even small changes (100ms) in page load times. I have personally seen conversion rates vary by 4x based on page load speed.

Re: The Controversial State of JavaScript Tooling

#74

In my experience some aspects of the JavaScript experience are great , and others are terrible . npm is great . It gives you an easy way of specifying your dependencies in your source tree, and makes it extremely easy for people who check out your repo to obtain them. People can run "npm install" and now they have a copy of all your dependencies in "./node_modules". It composes nicely too: "npm install" also pulls th…

If you're trying to test client side javascript with phantom + jasmine through gulp there are a few options.

I googled "gulp jasmine phantom" and found 3 options at the top, one of them being under the jasmine org on github. The other 2 seem to have similar APIs to the one under the jasmine org.

Re: The Controversial State of JavaScript Tooling

#75

> People take libraries like lodash – or jQuery, as we analyzed earlier – and insert the whole thing into their codebases. If a simple bundler plugin could deal with getting rid of everything in lodash they aren’t using, footprint is one less thing we’d have to worry about. If you use Google CDN, why does it matter how big jQuery is? If N people use their own "smaller" M-byte copy of jQuery, browsers will have to dow…

> If you use Google CDN, why does it matter how big jQuery is?

1. Most people won't have the version you wanted to use cached from the location you were trying to use it from. Studies show hit rates on requests for libraries on "shared" CDNs are very low in real world conditions. (Also, caches are small. Oh, you wanted 2.3.4r17 of BigLib? I've only got 2.3.4r18 cached; I'll go ahead and delete that so I have room to download your new copy.)

2. We don't get have HTTP/2, which means that while the number of bytes is important, so is the number of requests. If your app can get by with JUST jQuery, that doesn't matter. But if you need jQuery, plus two plugins, and lodash, and a promise polyfill, and...then all of a sudden your performance starts to be dominated by the number of requests being made, and (again) in real world situations you may see your effective load times improve if you concatenate your libraries.

The dream is "just list the libraries you need and let the browser sort it out super fast". The reality is a long way from it, and I don't think telling people "just use a CDN!" is currently good advice.

Re: The Controversial State of JavaScript Tooling

#76
post #17

Earlier quoted context omitted.

I believe the main problem with googles cdn is it can prevent Chinese users from visiting your site

This can be solved through the use of a local fallback if the request to the Google CDN returns 404.

Needs 1 or more of:

Handling out-of-order js file loading

Duplicate loading prevention

A way to deal with a file that is timing out (holding up page load)

Ideally using async property for script tags

AFAIK most CDN versions of popular libs don't support what you need, so you might as well load locally...

Re: The Controversial State of JavaScript Tooling

#77
post #68

> Tree-shaking is a game breaker To my knowledge, this has never, ever, worked well enough in a dynamic environment. Smalltalkers have spent over 3 decades trying to get this to work. What became the Smalltalk industry standard? Some form of code loading, often based on source code management. Anyone who is doing tooling/library work in a dynamic environment needs to delve into the history of Smalltalk and ask if it…

All of Google, and most ClojureScript users would like to disagree with you. Google Closure has been successfully tree-shaking since it was released, in 2009. ClojureScript uses Closure for an optimization path, so the majority of CLJS apps in production (CircleCI, Prismatic, to name a few) use tree-shaking on every deploy.

It's not as simple as you're suggesting. With Closure you sometimes have to rewrite otherwise correct and idiomatic JavaScript significantly to avoid it breaking during compilation.

Re: The Controversial State of JavaScript Tooling

#78
post #70
post #19

Are there any documented cases of a business failing because their JS payload was too large? I get that smaller code is easier to understand/work with, but I've never been able to internalize the desire for small payload -- just doesn't seem like it ever matters outside of philosophic reasons for saving user's bandwidth (especially if it comes with a steep tooling cost). It strikes me as a technical pursuit in search…

Google found a 0.5 second delay caused a 20% decrease in repeat traffic, that persisted after the delay went away ( http://glinden.blogspot.com/2006/11/marissa-mayer-at-web-20.... ) Amazon found every 100ms slower the site loaded, they lost 1% in revenue: http://www.gduchamp.com/media/StanfordDataMining.2006-11-28.... Walmart.com found a very large change in conversion rate based on page load times: ( http://www.slid…

> My own customers have seen 4x different conversion rate, when grouped by page load time

Was that a controlled test?

If just a correlation, then other variables might confound i.e. users from overseas, users with a slow connection, users with a slow computer.

Agree with you though!

Re: The Controversial State of JavaScript Tooling

#79

Something that's been concerning me about the current approach to web development in particular is the accumulation of unacknowledged -- and increasingly unmeasurable -- technical debt. I'm not sure that's precisely the right phrase, but here's what I mean: we all (should) know about technical debt in our own projects, but we also know that every project accumulates technical debt. When we build our projects on top o…

I think if anything you're being too kind here. The way dependencies are typically handled in the Node/NPM ecosystem is horrendous, and this has serious negative implications for the stability and longevity of almost any project built within that ecosystem today.

Unfortunately, modern web development is led, at least in publicity terms, by people who think phrases like "move fast and break things" and "living standard" are cool. The trouble is, what actually happens if you follow those people is that you break lots of things very quickly and you have no stable standards the help everyone do better.

Re: The Controversial State of JavaScript Tooling

#80
post #19

Are there any documented cases of a business failing because their JS payload was too large? I get that smaller code is easier to understand/work with, but I've never been able to internalize the desire for small payload -- just doesn't seem like it ever matters outside of philosophic reasons for saving user's bandwidth (especially if it comes with a steep tooling cost). It strikes me as a technical pursuit in search…

As a user have you never clicked the back button because the page was taking too long to load?

Businesses won't fail outright, but they will probably lose users/customers who decide not to spend time on the site because of load speed.

Post reply on HN