16 ms·

The Controversial State of JavaScript Tooling

156 points by lolptdr 11y ago

pspeter3 11y ago
At Asana we now just Bazel [http://www.bazel.io http://www.bazel.io] and TypeScript for our front end code. It made the tooling dramatically simpler.
pbowyer 11y ago
A fantastic post. If only to find someone else talking about the downsides of hypermodularization. > Unfortunately, the spirit and praise of the web in Remy’s post isn’t shared by many of these articles. To the contrary, the web development community is flooding in skepticism, negativity, and pessimism. I started building on the web a year or two after Remy. I believe one reason for the lack of praise is the reason people came to the industry. He & I came because we loved the web, we loved to see what could be done. Today, the web's an entirely different commercial being. People do this as a job (as do I, which I'm very thankful for), they have less time to see what can be done (constructive contributions take effort) and time is money, so let's develop fast and move on, slagging off everything as we go. I've been jaded, I'm guilty of being negative about everything. But I do see hope.
- kasey_junk 11y ago
  I heard similar opinions in 1998. I think it probably has less to do with the state of the industry & more to do with the state of the career of the observer.
hodwik 11y ago
The web community is flooded in negativity because it was swamped by kids with overly idealistic, unrealistic, and heroic ideas about what the web was going to be post-Facebook. Those people then realized that the web is, like all things, both real and imperfect. So now they're upset. This is all part of growing up. People who have been involved with the web for a while are not in any way more jaded then before. They already witnessed PHP, PERL, Java Applets, Flash, the browser wars, and so on.
- ktRolster 11y ago
  > They already witnessed PHP, PERL, Java Applets, Flash, the browser wars, and so on. It's frustrating that the situation hasn't improved. I thought by now the web would have a clean, easy system to work with. At the rate things are going, I don't have much hope before 2030.
  - gedy 11y ago
    Come'on it's way better than before. Before you could barely get the UI you wanted to work at all, now its mostly techy-debates about tooling and patterns.
    - pekk 11y ago
      Whether it's better than before is extremely debatable. Cross-browser compatibility was a major issue, and it has improved some. But the problem in the 90s wasn't whether you could get the UI you wanted to work, and even if that was the problem, it still isn't solved. Actually, the consensus I remember from back then was that Javascript sucked. I guess the solution to that problem was to have more Javascript? We have actually gone backwards in terms of ideas like "semantic markup" and most websites are no longer fit for viewing in Lynx. Which also means accessibility has gotten worse. Bloat is worse than ever and privacy issues are worse than ever. Power over the internet is concentrated in the hands of huge corporations who run crummy walled gardens. At least in the 90s most internet users agreed that AOL's walled garden was a bad idea, but now everyone comes out of the woodwork to argue in favor of Facebook or the App Store. I'd say things are worse than before.
      - gedy 11y ago
        I'm coming from a "end-result"-driven opinion about making something that works. It was a huge hurdle just to do pretty much anything beyond display text documents, so that was my problem when building web apps. As to you your last point - yes true, but I think it's much worse with non-web technology and native apps!
draw_down 11y ago
I thought this was a decent survey of where we're at, but I'm not sure what to take away. I don't care for "opinionated" as a description of tools or code, nor its opposite. It doesn't really mean anything, in my... opinion.
sotojuan 11y ago
It's interesting how none of the JS/tooling fatigue discussions mention Ember, which has one public-facing tool.
- aikah 11y ago
  i wouldn't use Ember precisely because it strongly suggests using a command line tool specifically for the framework. I personally ended up with Typescript as a language + Bower for package management. When it comes to frameworks it is either the framework adapts my toolset or I don't use it. I refuse to compromise and embrace yet another asset pipeline or build tool, no matter how "good" the framework is supposed to be. Typescript support both decorators and JSX, so I can tolerate working with either Angular 2 and React. And since build steps are mandatory in Front End development I, at least, can take advantage of static typing.
  - sotojuan 11y ago
    Fair point. My comment was pointing out how Ember isn't mentioned at all, not that it's necessarily better.
- anonyfox 11y ago
  So true. Ember is the antidote right now for the frontend land. - MVC (Backbone's big thing) - Two way binding (Angular's big thing) - Components (React's big thing) - SSR like the others now (FastBoot) - High performance with the Glimmer Engine (should beat react in theory) - Books. - dedicated package repository (emberaddons) - actually community driven - stable + mature (+ seamless upgrade paths) - and many more advantages plus, as you said, the ember-cli tool, that gets you up to speed fast. The tooling makes the final success, just have a look at go... the language appears fairly weak/trivial, but the tooling is excellent. I could freak out everytime I have to set up an react project, weighing everyones opinions about every little package for every usecase, IMO react shifts the complexity from the UI to the tooling. Ember is just perfect and the only real option I could recommend right now, and I'm just sick of thousands of "me too!" approaches for everything, this extreme diversification cripples actual progress to a halt.
dreamdu5t 11y ago
Web developers need more homotopy type theory, and to curb their NIMH hypermodularization epedemic.
- draw_down 11y ago
  What could this comment mean, I wonder.
  - jandrese 11y ago
    I was trying to figure out if it was some Markov chain built from the article.
venomsnake 11y ago
The modern JS ecosystem have that enterprise java feel to it of 2010.
- deleted 11y ago
  [deleted]
alextgordon 11y ago
> 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 download M*N bytes, as opposed to 0 bytes if you use the cached full version. A profound waste of bandwidth. My advice: Use Google CDN, for less common stuff use cdnjs. Don't adulterate libraries!
- dpkrjb 11y ago
  I believe the main problem with googles cdn is it can prevent Chinese users from visiting your site
  - vosper 11y ago
    I would imagine it's China that's preventing Chinese users from visiting your site, not Google?
    - ybx 11y ago
      Yes, but the end result is the same
  - alextgordon 11y ago
    I guess, but if you go to the trouble of localising your website into Chinese, then loading a self-hosted version of the library for Chinese users doesn't seem like much extra work.
  - everfree 11y ago
    This can be solved through the use of a local fallback if the request to the Google CDN returns 404.
    - robocat 11y ago
atemerev 11y ago
Babel got it wrong. Hypermodularisation is a good thing in user-facing code. Here we should thrive to shave off every last byte. But Babel is a tool for developers. We don't need configuration explosion and endless plugins. We need all batteries included. The very purpose of Babel is "hey, I want to write hip code like the rest of cool kids of the block; now, let it run everywhere". Who needs to configure that?
- LewisJEllis 11y ago
  I agree that Babel doesn't get every single thing right, in much the same way that everything manages to get something wrong, but I don't think you're giving credit to the benefits of its modularity. Another "purpose" of babel is "hey, I want to implement an upcoming ECMAScript feature in an extensible and relatively self-contained way so I don't have to go digging deep inside someone's codebase." Or, it's also "hey, I only need these 3 features and I want my build times to stay as low as possible." For the use case you describe, there are presets provided to make that quite simple.
- WorldMaker 11y ago
  Except that Babel has always ran in the browser, too and "hip code" is a constantly shifting target: ES2016 was just finalized (exponent operator, Array.prototype.includes), and much of ES2015 is already implemented in current browsers, but certainly not all of it and the sets implemented in each browser is different. Hypermodularization should mean that Babel stays relevant with new standards (this month's ES2016 announcement, plus we already have a good idea of what should be in ES2017 with the new "continuous deployment" approach to the ES standards) and doesn't get bogged down in legacy code as browsers adopt the standards.
swanson 11y ago
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 of a problem -- but certainly willing to be convinced otherwise.
- s986s 11y ago
  Site loading speed is very important https://blog.kissmetrics.com/loading-time/ https://blog.kissmetrics.com/loading-time/
- rickboyce 11y ago
  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.
  - arohner 11y ago
    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.
- tyingq 11y ago
  I don't know that it would result in a business failing, but there's certainly lost opportunity. Marks and Spencer is a fairly recent example, perhaps not JS payload specifically, but lower conversions related to site performance. Considering the audience might help as well. For example, if rural U.S. dwellers are a demographic you want, many of them are on low bandwidth connections.
- arohner 11y ago
lhnz 11y ago
The problem with hypermodularization is that it takes time to make a decision on what module to use for every task. If you have to to do this with 100s of modules, you're wasting a lot of valuable time. Does anybody know a quick way of making the right decision? NPM is like a crowded graveyard nowadays (or like .com domain names - where all of the good module names have been taken along time ago and now all the best practice modules have completely irrelevant names). There are thousands of buggy modules in which development has stalled, and it's easy to waste a lot of time trying to separate the wheat from the chaff. I personally sometimes have to open up 5+ Github repositories to check their last commit, number of contributors, interfaces, code quality, unanswered issues, etc. Only after doing so am I able to make a decision. In terms of knowing what's cutting-edge practice it seems you have to watch Twitter a lot and be careful not to follow every single bad idea. I can't imagine what it'll be like to search for a module to handle something as common as config in a couple of years. Even when you constrain yourself to something like '12 factor config' there are many different implementations. Don't even get me started on the insane assembly required to get webpack-, babel-, cssmodules-, and postcss- to all work together. The problem is only going to get worse.
- taurath 11y ago
  Just like the difference between pre-internet post-internet days, the problem is no longer finding the information, its filtering the large amounts of available information. Same with libraries and modules - there's probably a module for a LOT of things. You eventually develop a good sense for what heuristics make a good module, and you develop in such a way that the cost of an accidental bad module is low. You can certainly find full-fledged frameworks out there that do everything for you and make your decisions for you, but the cost of getting that wrong is far higher than a bad module.
- wwweston 11y ago
  > I personally sometimes have to open up 5+ Github repositories to check their last commit, number of contributors, interfaces, code quality, unanswered issues, etc. Only one of these, it seems to me, is likely to be consistently related to the quality of the module.
stcredzero 11y ago
> 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 was already tried and what the problems were. Chances are, it was already tried, and that there's useful experiential data there.
- arohner 11y ago
  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.
  - Silhouette 11y ago
    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.
    - chrisoakman 11y ago
      FYI - the JavaScript output of the ClojureScript compiler is designed to be compatible with the Google Closure Compiler in Advanced mode. In other words, CLJS users don't have to do anything special to benefit from the power of Google Closure. It just works :)
    - arohner 11y ago
      If you design your app to use Closure from the start, it's not a problem at all, and as a sibling comment said, CLJS apps get it mostly for free. The entire JS toolchain lost five to ten years by not adopting Closure. I suspect that in a year or two, someone will release a webpack plugin that does the exact same thing Closure did, with the exact same constraints.
haberman 11y ago
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 the dependencies of your dependencies. Babel is great. Sure, I've heard some complaints lately about their latest changes, but so far this hasn't affected me as a user. Babel for me means that I get to write using the most modern ES6/ES7 features and then compile to ES5 for compatibility. For me it works great and mostly hassle free. The frameworks themselves are great. Not perfect sure, but there are lots of great ideas floating around in React, Angular, d3, moment.js, etc. and the packages built on top of them. Whatever you want to do there is a library out there that someone has put a lot of love into. There is a lot of choice -- yes, maybe sometimes a little bit too much, but I'd rather have that than too little. Flow is great (and I hear TypeScript is too, and getting better). I can't tell you how nice it is to be able to declare static types when you want to and hear about type errors at compile time. Maybe not everybody's cup of tea, but I love it. The build systems, minifiers, test runners, etc. are terrible. By far the worst part of JS development for me is figuring out how to glue it all together. When I try to figure it out it's like entering an infinitely complex maze where none of the passages actually lead anywhere. -- For example, let's say you want to run some Jasmine tests under PhantomJS. Jasmine is a popular unit testing framework and PhantomJS is a popular headless browser, scriptable using JavaScript. Both very cool technologies, but how can you use them together? This is a real example: it's something I really wanted to do, but in the end I literally could not figure out how and gave up. Phantom JS claims that it supports Jasmine (http://phantomjs.org/headless-testing.html http://phantomjs.org/headless-testing.html) though it gives several options for test runners: Chutzpah, grunt-contrib-jasmine, guard-jasmine, phantom-jasmine. Time to enter the maze! Chutzpah looks promising (http://mmanela.github.io/chutzpah/ http://mmanela.github.io/chutzpah/) -- it says it lets you run tests under a command line. It says it "supports the QUnit, Jasmine and Mocha testing frameworks" and you can get it by using "nuget or chocolatey". Dig a little deeper and it starts to become clear that this is a very Windows-centric tool -- nuget says it requires Visual Studio and chocolatey is Windows-only. Our maze has run into a dead-end. Moving on to grunt-contrib-jasmine. I don't really want to use this because I'm currently using Gulp (Grunt's competitor), but let's check it out. We end up at this page (https://github.com/gruntjs/grunt-contrib-jasmine https://github.com/gruntjs/grunt-contrib-jasmine). This page is sort of a quintessential "JavaScript maze". It contains a lot of under-explained jargon and links to other plugins. And it gives me no idea how to do basic things like "include all my node_modules" (maybe I should list each ./node_module/foo dir explicitly under "vendor"?) Moving on to guard-jasmine, I end up at https://github.com/guard/guard-jasmine https://github.com/guard/guard-jasmine, and it's clear now that I've entered a Ruby neighborhood of the maze: everything is talking about the "Rails asset pipeline", adding Guard into "your Gemfile" (I don't have a Gemfile!!). I really don't want to introduce a Ruby dependency into my build just for the privilege of gluing two JavaScript technologies together (Jasmine and PhantomJS). The final option in the list was phantom-jasmine, bringing us here: https://github.com/jcarver989/phantom-jasmine https://github.com/jcarver989/phantom-jasmine. It's been a while so I don't remember everything I went through trying to make this work. But I was ultimately unsuccessful.
gsmethells 11y ago
Hypermodularization sounds like the latest euphemism for Dependency Hell (tm).
- EvanPlaice 11y ago
  Dependency hell is caused by the inability to sanely identify and (if necessary) support multiple versions of a dependency. The primary cause of dependency hell comes from installing and using global dependencies because there's no way to predetermine all of the dependencies that every module and/or application on a system will use. Thr Javascript ecosystem actively discourages using global dependencies except for CLI tooling. This is talking specifically about an optimization problem. How to minimize source size by only inporting code that is used directly in the appplication. AFAIK, no other platforms don't attempt to solve this problem because it's a non-issue except where you're sending code over a network to be executed remotely. For example, imagine if you had to send the entire Java Runtime Environment over the wire every time you loaded a website.
  - wvenable 11y ago
    Platforms that are completely compiled will do dead code removal. JavaScript is very dynamic so it can be hard to tell what is and is not dead code.
  - paulddraper 11y ago
    npm3 installs flat, right?
    - EvanPlaice 11y ago
      Yep, NPM is transitioning to flat in V3. Partly because of the nested folder limits in Windows, partly to reduce the ridiculous amount of dependency nesting that occurs with the current model. JSPM already uses a flat dependency structure. If you look at how it maps dependencies (and specific versions of dependencies) in config.js it makes a lot of sense. The only feature it's missing is the ability to easily search and list multiple versions of the same dependency.
TimJYoung 11y ago
Speaking of controversial: I think things are going to keep being bad until developers realize that the problem isn't technical, but rather economic. Back before the current "give it all away for free" trend became a thing, commercialization of software was a given and allowed "winners" to emerge from the chaos. The merits of the "winners" isn't important here, it's the stability that comes with it. As long as everything is given away for free and there are no barriers to entry, you'll keep ending up with chaos and unmanageable churn whereby your job as a software developer has now morphed into a software tester/evaluator for every single piece of functionality that you need and don't want to write yourself. When you have to actually put your money on the line and have an actual business presence on the web, it's a completely different mindset from "I'm going to write this small library and pop it up on GitHub for free, so who cares if there's documentation or if the software even works as described". The fact that there are developers that are professional and thorough and still give away their software is a minor miracle. But, it's not wise to count on the charity of such developers for the long-term because it isn't realistic. As more and more one-offs are created, it becomes much harder to distinguish one's software from the rest of the pack, so developers will simply not even attempt to do so. The Apple store is a perfect example of this problem.
- EvanPlaice 11y ago
  So look at the projects that stand for a higher degree of quality and hire the developers that author them so they can invest the time to battle test the code. Since we're talking from an economic perspective. Whoch is more cost (ie time and money) effective. Tasking an internal developer with no domain knowledge to build a module from scratch to cover similar functionality of an OSS project. Or hire an OSS dev who already has a deep understanding of the domain as well as working code to battle test the existing OSS implementation. If you're talking in terms of risk, the latter is an easy sell. The problem is, most companies are too concerned with building a stable of 'rockstars' that can support their pathological adherence to NIH (Not Invented Here) syndrome. I'd argue that the most successful companies already use this strategy. Select exceptional devs from the OSS community to build hogh quality tools as open source projects. The community battle tests the tools and accelerates the discovery of new and useful capability. Meanwhile, the company leverages the tools internally to compose their own proprietary platform in the form of domain-specific applications and services. The major disconnect is, most software based business want to have their cake and eat it too. It's not difficult to determine when an OSS project reaches enough success to transition from one-off to mass appeal. OSS is an ecosystem of brutal software darwinism. Projects that survive experience growth in usage and improvement over time. Projects that don't, stagnate and remain or eventually become irrelevant.
chipotle_coyote 11y ago
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 of other projects, our work now has the potential to be affected by the technical debt -- bugs, poor optimizations, whatever -- in the underlying projects. Obviously, this has always been true to varying degrees. But we've reached a point where modern web applications are pulling in dozens of dependencies in both production and development toolchains, and increasingly those dependencies are themselves built on top of other dependencies. I don't want to suggest we should be writing everything from scratch and constantly re-inventing wheels, but when even modest applications end up with hundreds of subdirectories in their local "node_modules" directory, it's hard not to wonder whether we're making things a little...fragile, even taking into account that many of those modules are related and form part of the same pseudo-modular project. Is this a completely ridiculous concern? (The answer may well be "yes," but I'd like to see a good argument why.)
- Silhouette 11y ago
  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.
  - r2dnb 11y ago
    >Move fast and break things You made my day, I never heard of that one... unbelievable !
    - 11y ago
EvanPlaice 11y ago
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 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.
- EvanPlaice 11y ago
  Not sure why this touched a nerve enough to be downvoted into oblivion. If it was the cheeky tl;dr I guess I can make a point to avoid any and all attempts at sarcasm in my future posts. As for the rest, I genuinely think it's a useful approach to consider 1. it's relies on future web standards not tools Tools come and go. Web standards never go. If the goal is to avoid technical debt, then don't write code in a way that will eventually be obsolete. 2. 'Abstractions are the solution to every problem, except the problem of too many abstractions' Except, when there's a viable strategy to provide access at multiple layers of abstraction. If we're finally getting a truly universal module standard, why not leverage it to improve our library APIs? It's not like we have to waste the time/energy/effort supporting multiple module non-standards anymore. The approach I outlined above provides much better usability with very little effort on the part of the dev implementing an API. 3. It doesn't rely on approaches that will eventually be obsolete Namely bundling. Tree shaking is great if the end goal is to analyze all dependencies and create an optimized bundle. Except for the fact that bundling will become an anti-pattern when HTTPv2 reaches widespread adoption.
bsimpson 11y ago
If tree-shaking is your jam, you'll be especially excited for Webpack 2: https://gist.github.com/sokra/27b24881210b56bbaff7 https://gist.github.com/sokra/27b24881210b56bbaff7
jordanlev 11y ago
I think the javascript ecosystem has a fundamental difference from all other languages/communites that came before it: it is universal. Hence I think a lot of the debates raging about the right tools come down to different people using it for different purposes. I doubt that everyone can consolidate on just one set of tools, because in javascript-land "everyone" means something different than other places. How can a tool that is good for a front-end designer who needs basic DOM manipulation also be the right tool for someone building an entire application in js and only using HTML as a delivery mechanism for their app bundle? I wish people would recognize in these discussions that their use-case might be different from others, and instead of talking about "the best tools", instead talk about "the best tools for this class of applications". So hopefully the toolset could be consolidated down to one clear choice for each class of usage. Then the biggest decision to make is deciding which type of application it is you're building.
- davedx 11y ago
  This is definitely part of it. JavaScript tooling encompasses back end, front end (progressive enhancement inside server generated web pages), front end (large single page apps), and a bunch of language flavours (ES5, ES6, ES7, TypeScript, JSX, to name a few). So it's understandable the tooling ecosystem is large and diverse, and that plumbing it all together can result in premature hair loss. We're using ES5 with AngularJS at work, and it's like a breath of fresh air ;)
mdavidn 11y ago
Interesting how the industry has come full circle. Static linking and dead code elimination is a problem we solved in the 1970s for compiled languages. Has the time come to adopt a proper linker for the web? Google's Closure Compiler has supported dead code elimination [1] since 2009, but the feature imposes some unpalatable restrictions. It never supported popular libraries like jQuery. The process is also rather slow, as Closure Compiler must analyze all code in the bundle at once. [1]: https://developers.google.com/closure/compiler/docs/compilation_levels#advanced_optimizations https://developers.google.com/closure/compiler/docs/compilat...
- virmundi 11y ago
  An interesting thing is how that applies to transpiled languages like ClojureScript. There are a lot of efficiencies gained by using ClojureScript with Google Closure. Even react is faster with Reagent.
szines 11y ago
I’ve been using ES6 modules in Ember.js development for two years now. Using Ember CLI is simplified down the dev process extreamly. The whole dev app development is so simple and fun with Ember. I don’t understand why people cry about it, the solution is exist, they should just use it. Thats all.
napperjabber 11y ago
One of the major differences between a jr and a sr IMO, is their ability to tell you what each one of those dependencies solves. If they don't know the sub-dependencies by heart, they didn't read the code or at least look it up outside of understanding the API. Than you have the maintenance developer, and everyone loves 'em. He just figures things out and helps you improve your code while you scream at him for not knowing the 'bigger picture'. Fun times.
justaaron 11y ago
One should consider the possibility that the entire web development industry is a giant busy-work factory making half-baked kluges to a fundamental problem that will never be papered over: http is a stateless protocol for sending hypertext. markup. meta-data and context for resources in a folder somewhere. It's a file-system thing. A web browser is a declarative-markup-tree rendering-engine with scriptable nodes, and the language chosen for scripting is an accident of history. Using http and web browsers in ways they never were intended to be used is possible, albeit painful. Now that we have virtual DOM's and isomorphic platforms like clojure/clojurescript and we compile to JS, now that we have JS on the server, now that we have our head so thoroughly up our ass that we forgot the point, now we can consider the circle of ridiculous nonsense complete... The world wide web took off, and we have to live with it's technical debt, or... The solution is simple, bold, and risky: 1) pick a port. (Nowadays that's even a joke. we tunnel everything over port 80.) 2) pick a protocol with some future (hey let's just tack websockets on as an upgrade, gradually get browser support, etc) 3) keep moving... I am not ultra impressed with the web of 2016... The web of 1996 was way cooler. I want a VRML3 rendering engine for a browser.
- justaaron 11y ago
  Oh, don't even get me started with build tools. Nowadays we have build tools to build build tools. I'm sorry, but when FRONT-END DEV considers build tools standard we are LOST lost lost... How many JS libraries and CSS scripts do we really need to embed in a page? How many of those functions or classes are even being used in that page? Why do I have to scroll to view source on a page with mostly text and a few colored boxes? Hand-coded html and css is not that hard folks... it's just the habits, the frameworks, etc... 1/4 of the web is powered by Wordpress wtf!?
  - justaaron 11y ago
    In a nutshell, I think, with some risk, that some innovators could literally pick a port, pick a protocol, and build a different kind of browser... once there is some content for that platform it's a matter of time before early adopters download one of these new class of browsers and so forth... it's how it happened the first time, and it's how pretty much everything happened... even games (second life) etc. and meanwhile, the web can go back to being a directory preview/ resource hyperlink web...

156 points by lolptdr 11y ago

At Asana we now just Bazel [http://www.bazel.io http://www.bazel.io] and TypeScript for our front end code. It made the tooling dramatically simpler.

pbowyer 11y ago

A fantastic post. If only to find someone else talking about the downsides of hypermodularization. > Unfortunately, the spirit and praise of the web in Remy’s post isn’t shared by many of these articles. To the contrary, the web development community is flooding in skepticism, negativity, and pessimism. I started building on the web a year or two after Remy. I believe one reason for the lack of praise is the reason people came to the industry. He & I came because we loved the web, we loved to see what could be done. Today, the web's an entirely different commercial being. People do this as a job (as do I, which I'm very thankful for), they have less time to see what can be done (constructive contributions take effort) and time is money, so let's develop fast and move on, slagging off everything as we go. I've been jaded, I'm guilty of being negative about everything. But I do see hope.

kasey_junk 11y ago
I heard similar opinions in 1998. I think it probably has less to do with the state of the industry & more to do with the state of the career of the observer.

hodwik 11y ago

The web community is flooded in negativity because it was swamped by kids with overly idealistic, unrealistic, and heroic ideas about what the web was going to be post-Facebook. Those people then realized that the web is, like all things, both real and imperfect. So now they're upset. This is all part of growing up. People who have been involved with the web for a while are not in any way more jaded then before. They already witnessed PHP, PERL, Java Applets, Flash, the browser wars, and so on.

ktRolster 11y ago
> They already witnessed PHP, PERL, Java Applets, Flash, the browser wars, and so on. It's frustrating that the situation hasn't improved. I thought by now the web would have a clean, easy system to work with. At the rate things are going, I don't have much hope before 2030.
- gedy 11y ago
  Come'on it's way better than before. Before you could barely get the UI you wanted to work at all, now its mostly techy-debates about tooling and patterns.
  - pekk 11y ago
    Whether it's better than before is extremely debatable. Cross-browser compatibility was a major issue, and it has improved some. But the problem in the 90s wasn't whether you could get the UI you wanted to work, and even if that was the problem, it still isn't solved. Actually, the consensus I remember from back then was that Javascript sucked. I guess the solution to that problem was to have more Javascript? We have actually gone backwards in terms of ideas like "semantic markup" and most websites are no longer fit for viewing in Lynx. Which also means accessibility has gotten worse. Bloat is worse than ever and privacy issues are worse than ever. Power over the internet is concentrated in the hands of huge corporations who run crummy walled gardens. At least in the 90s most internet users agreed that AOL's walled garden was a bad idea, but now everyone comes out of the woodwork to argue in favor of Facebook or the App Store. I'd say things are worse than before.
    - gedy 11y ago
      I'm coming from a "end-result"-driven opinion about making something that works. It was a huge hurdle just to do pretty much anything beyond display text documents, so that was my problem when building web apps. As to you your last point - yes true, but I think it's much worse with non-web technology and native apps!

draw_down 11y ago

I thought this was a decent survey of where we're at, but I'm not sure what to take away. I don't care for "opinionated" as a description of tools or code, nor its opposite. It doesn't really mean anything, in my... opinion.

sotojuan 11y ago

It's interesting how none of the JS/tooling fatigue discussions mention Ember, which has one public-facing tool.

aikah 11y ago
i wouldn't use Ember precisely because it strongly suggests using a command line tool specifically for the framework. I personally ended up with Typescript as a language + Bower for package management. When it comes to frameworks it is either the framework adapts my toolset or I don't use it. I refuse to compromise and embrace yet another asset pipeline or build tool, no matter how "good" the framework is supposed to be. Typescript support both decorators and JSX, so I can tolerate working with either Angular 2 and React. And since build steps are mandatory in Front End development I, at least, can take advantage of static typing.
- sotojuan 11y ago
  Fair point. My comment was pointing out how Ember isn't mentioned at all, not that it's necessarily better.
anonyfox 11y ago
So true. Ember is the antidote right now for the frontend land. - MVC (Backbone's big thing) - Two way binding (Angular's big thing) - Components (React's big thing) - SSR like the others now (FastBoot) - High performance with the Glimmer Engine (should beat react in theory) - Books. - dedicated package repository (emberaddons) - actually community driven - stable + mature (+ seamless upgrade paths) - and many more advantages plus, as you said, the ember-cli tool, that gets you up to speed fast. The tooling makes the final success, just have a look at go... the language appears fairly weak/trivial, but the tooling is excellent. I could freak out everytime I have to set up an react project, weighing everyones opinions about every little package for every usecase, IMO react shifts the complexity from the UI to the tooling. Ember is just perfect and the only real option I could recommend right now, and I'm just sick of thousands of "me too!" approaches for everything, this extreme diversification cripples actual progress to a halt.

dreamdu5t 11y ago

Web developers need more homotopy type theory, and to curb their NIMH hypermodularization epedemic.

draw_down 11y ago
What could this comment mean, I wonder.
- jandrese 11y ago
  I was trying to figure out if it was some Markov chain built from the article.

venomsnake 11y ago

The modern JS ecosystem have that enterprise java feel to it of 2010.

deleted 11y ago
[deleted]

alextgordon 11y ago

> 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 download M*N bytes, as opposed to 0 bytes if you use the cached full version. A profound waste of bandwidth. My advice: Use Google CDN, for less common stuff use cdnjs. Don't adulterate libraries!

dpkrjb 11y ago
I believe the main problem with googles cdn is it can prevent Chinese users from visiting your site
- vosper 11y ago
  I would imagine it's China that's preventing Chinese users from visiting your site, not Google?
  - ybx 11y ago
    Yes, but the end result is the same
- alextgordon 11y ago
  I guess, but if you go to the trouble of localising your website into Chinese, then loading a self-hosted version of the library for Chinese users doesn't seem like much extra work.
- everfree 11y ago
  This can be solved through the use of a local fallback if the request to the Google CDN returns 404.
  - robocat 11y ago

atemerev 11y ago

Babel got it wrong. Hypermodularisation is a good thing in user-facing code. Here we should thrive to shave off every last byte. But Babel is a tool for developers. We don't need configuration explosion and endless plugins. We need all batteries included. The very purpose of Babel is "hey, I want to write hip code like the rest of cool kids of the block; now, let it run everywhere". Who needs to configure that?

LewisJEllis 11y ago
I agree that Babel doesn't get every single thing right, in much the same way that everything manages to get something wrong, but I don't think you're giving credit to the benefits of its modularity. Another "purpose" of babel is "hey, I want to implement an upcoming ECMAScript feature in an extensible and relatively self-contained way so I don't have to go digging deep inside someone's codebase." Or, it's also "hey, I only need these 3 features and I want my build times to stay as low as possible." For the use case you describe, there are presets provided to make that quite simple.
WorldMaker 11y ago
Except that Babel has always ran in the browser, too and "hip code" is a constantly shifting target: ES2016 was just finalized (exponent operator, Array.prototype.includes), and much of ES2015 is already implemented in current browsers, but certainly not all of it and the sets implemented in each browser is different. Hypermodularization should mean that Babel stays relevant with new standards (this month's ES2016 announcement, plus we already have a good idea of what should be in ES2017 with the new "continuous deployment" approach to the ES standards) and doesn't get bogged down in legacy code as browsers adopt the standards.

swanson 11y ago

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 of a problem -- but certainly willing to be convinced otherwise.

s986s 11y ago
Site loading speed is very important https://blog.kissmetrics.com/loading-time/ https://blog.kissmetrics.com/loading-time/
rickboyce 11y ago
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.
- arohner 11y ago
  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.
tyingq 11y ago
I don't know that it would result in a business failing, but there's certainly lost opportunity. Marks and Spencer is a fairly recent example, perhaps not JS payload specifically, but lower conversions related to site performance. Considering the audience might help as well. For example, if rural U.S. dwellers are a demographic you want, many of them are on low bandwidth connections.
arohner 11y ago

lhnz 11y ago

The problem with hypermodularization is that it takes time to make a decision on what module to use for every task. If you have to to do this with 100s of modules, you're wasting a lot of valuable time. Does anybody know a quick way of making the right decision? NPM is like a crowded graveyard nowadays (or like .com domain names - where all of the good module names have been taken along time ago and now all the best practice modules have completely irrelevant names). There are thousands of buggy modules in which development has stalled, and it's easy to waste a lot of time trying to separate the wheat from the chaff. I personally sometimes have to open up 5+ Github repositories to check their last commit, number of contributors, interfaces, code quality, unanswered issues, etc. Only after doing so am I able to make a decision. In terms of knowing what's cutting-edge practice it seems you have to watch Twitter a lot and be careful not to follow every single bad idea. I can't imagine what it'll be like to search for a module to handle something as common as config in a couple of years. Even when you constrain yourself to something like '12 factor config' there are many different implementations. Don't even get me started on the insane assembly required to get webpack-, babel-, cssmodules-, and postcss- to all work together. The problem is only going to get worse.

taurath 11y ago
Just like the difference between pre-internet post-internet days, the problem is no longer finding the information, its filtering the large amounts of available information. Same with libraries and modules - there's probably a module for a LOT of things. You eventually develop a good sense for what heuristics make a good module, and you develop in such a way that the cost of an accidental bad module is low. You can certainly find full-fledged frameworks out there that do everything for you and make your decisions for you, but the cost of getting that wrong is far higher than a bad module.
wwweston 11y ago
> I personally sometimes have to open up 5+ Github repositories to check their last commit, number of contributors, interfaces, code quality, unanswered issues, etc. Only one of these, it seems to me, is likely to be consistently related to the quality of the module.

stcredzero 11y ago

> 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 was already tried and what the problems were. Chances are, it was already tried, and that there's useful experiential data there.

arohner 11y ago
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.
- Silhouette 11y ago
  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.
  - chrisoakman 11y ago
    FYI - the JavaScript output of the ClojureScript compiler is designed to be compatible with the Google Closure Compiler in Advanced mode. In other words, CLJS users don't have to do anything special to benefit from the power of Google Closure. It just works :)
  - arohner 11y ago
    If you design your app to use Closure from the start, it's not a problem at all, and as a sibling comment said, CLJS apps get it mostly for free. The entire JS toolchain lost five to ten years by not adopting Closure. I suspect that in a year or two, someone will release a webpack plugin that does the exact same thing Closure did, with the exact same constraints.

haberman 11y ago

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 the dependencies of your dependencies. Babel is great. Sure, I've heard some complaints lately about their latest changes, but so far this hasn't affected me as a user. Babel for me means that I get to write using the most modern ES6/ES7 features and then compile to ES5 for compatibility. For me it works great and mostly hassle free. The frameworks themselves are great. Not perfect sure, but there are lots of great ideas floating around in React, Angular, d3, moment.js, etc. and the packages built on top of them. Whatever you want to do there is a library out there that someone has put a lot of love into. There is a lot of choice -- yes, maybe sometimes a little bit too much, but I'd rather have that than too little. Flow is great (and I hear TypeScript is too, and getting better). I can't tell you how nice it is to be able to declare static types when you want to and hear about type errors at compile time. Maybe not everybody's cup of tea, but I love it. The build systems, minifiers, test runners, etc. are terrible. By far the worst part of JS development for me is figuring out how to glue it all together. When I try to figure it out it's like entering an infinitely complex maze where none of the passages actually lead anywhere. -- For example, let's say you want to run some Jasmine tests under PhantomJS. Jasmine is a popular unit testing framework and PhantomJS is a popular headless browser, scriptable using JavaScript. Both very cool technologies, but how can you use them together? This is a real example: it's something I really wanted to do, but in the end I literally could not figure out how and gave up. Phantom JS claims that it supports Jasmine (http://phantomjs.org/headless-testing.html http://phantomjs.org/headless-testing.html) though it gives several options for test runners: Chutzpah, grunt-contrib-jasmine, guard-jasmine, phantom-jasmine. Time to enter the maze! Chutzpah looks promising (http://mmanela.github.io/chutzpah/ http://mmanela.github.io/chutzpah/) -- it says it lets you run tests under a command line. It says it "supports the QUnit, Jasmine and Mocha testing frameworks" and you can get it by using "nuget or chocolatey". Dig a little deeper and it starts to become clear that this is a very Windows-centric tool -- nuget says it requires Visual Studio and chocolatey is Windows-only. Our maze has run into a dead-end. Moving on to grunt-contrib-jasmine. I don't really want to use this because I'm currently using Gulp (Grunt's competitor), but let's check it out. We end up at this page (https://github.com/gruntjs/grunt-contrib-jasmine https://github.com/gruntjs/grunt-contrib-jasmine). This page is sort of a quintessential "JavaScript maze". It contains a lot of under-explained jargon and links to other plugins. And it gives me no idea how to do basic things like "include all my node_modules" (maybe I should list each ./node_module/foo dir explicitly under "vendor"?) Moving on to guard-jasmine, I end up at https://github.com/guard/guard-jasmine https://github.com/guard/guard-jasmine, and it's clear now that I've entered a Ruby neighborhood of the maze: everything is talking about the "Rails asset pipeline", adding Guard into "your Gemfile" (I don't have a Gemfile!!). I really don't want to introduce a Ruby dependency into my build just for the privilege of gluing two JavaScript technologies together (Jasmine and PhantomJS). The final option in the list was phantom-jasmine, bringing us here: https://github.com/jcarver989/phantom-jasmine https://github.com/jcarver989/phantom-jasmine. It's been a while so I don't remember everything I went through trying to make this work. But I was ultimately unsuccessful.

gsmethells 11y ago

Hypermodularization sounds like the latest euphemism for Dependency Hell (tm).

EvanPlaice 11y ago
Dependency hell is caused by the inability to sanely identify and (if necessary) support multiple versions of a dependency. The primary cause of dependency hell comes from installing and using global dependencies because there's no way to predetermine all of the dependencies that every module and/or application on a system will use. Thr Javascript ecosystem actively discourages using global dependencies except for CLI tooling. This is talking specifically about an optimization problem. How to minimize source size by only inporting code that is used directly in the appplication. AFAIK, no other platforms don't attempt to solve this problem because it's a non-issue except where you're sending code over a network to be executed remotely. For example, imagine if you had to send the entire Java Runtime Environment over the wire every time you loaded a website.
- wvenable 11y ago
  Platforms that are completely compiled will do dead code removal. JavaScript is very dynamic so it can be hard to tell what is and is not dead code.
- paulddraper 11y ago
  npm3 installs flat, right?
  - EvanPlaice 11y ago
    Yep, NPM is transitioning to flat in V3. Partly because of the nested folder limits in Windows, partly to reduce the ridiculous amount of dependency nesting that occurs with the current model. JSPM already uses a flat dependency structure. If you look at how it maps dependencies (and specific versions of dependencies) in config.js it makes a lot of sense. The only feature it's missing is the ability to easily search and list multiple versions of the same dependency.

TimJYoung 11y ago

Speaking of controversial: I think things are going to keep being bad until developers realize that the problem isn't technical, but rather economic. Back before the current "give it all away for free" trend became a thing, commercialization of software was a given and allowed "winners" to emerge from the chaos. The merits of the "winners" isn't important here, it's the stability that comes with it. As long as everything is given away for free and there are no barriers to entry, you'll keep ending up with chaos and unmanageable churn whereby your job as a software developer has now morphed into a software tester/evaluator for every single piece of functionality that you need and don't want to write yourself. When you have to actually put your money on the line and have an actual business presence on the web, it's a completely different mindset from "I'm going to write this small library and pop it up on GitHub for free, so who cares if there's documentation or if the software even works as described". The fact that there are developers that are professional and thorough and still give away their software is a minor miracle. But, it's not wise to count on the charity of such developers for the long-term because it isn't realistic. As more and more one-offs are created, it becomes much harder to distinguish one's software from the rest of the pack, so developers will simply not even attempt to do so. The Apple store is a perfect example of this problem.

EvanPlaice 11y ago
So look at the projects that stand for a higher degree of quality and hire the developers that author them so they can invest the time to battle test the code. Since we're talking from an economic perspective. Whoch is more cost (ie time and money) effective. Tasking an internal developer with no domain knowledge to build a module from scratch to cover similar functionality of an OSS project. Or hire an OSS dev who already has a deep understanding of the domain as well as working code to battle test the existing OSS implementation. If you're talking in terms of risk, the latter is an easy sell. The problem is, most companies are too concerned with building a stable of 'rockstars' that can support their pathological adherence to NIH (Not Invented Here) syndrome. I'd argue that the most successful companies already use this strategy. Select exceptional devs from the OSS community to build hogh quality tools as open source projects. The community battle tests the tools and accelerates the discovery of new and useful capability. Meanwhile, the company leverages the tools internally to compose their own proprietary platform in the form of domain-specific applications and services. The major disconnect is, most software based business want to have their cake and eat it too. It's not difficult to determine when an OSS project reaches enough success to transition from one-off to mass appeal. OSS is an ecosystem of brutal software darwinism. Projects that survive experience growth in usage and improvement over time. Projects that don't, stagnate and remain or eventually become irrelevant.

chipotle_coyote 11y ago

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 of other projects, our work now has the potential to be affected by the technical debt -- bugs, poor optimizations, whatever -- in the underlying projects. Obviously, this has always been true to varying degrees. But we've reached a point where modern web applications are pulling in dozens of dependencies in both production and development toolchains, and increasingly those dependencies are themselves built on top of other dependencies. I don't want to suggest we should be writing everything from scratch and constantly re-inventing wheels, but when even modest applications end up with hundreds of subdirectories in their local "node_modules" directory, it's hard not to wonder whether we're making things a little...fragile, even taking into account that many of those modules are related and form part of the same pseudo-modular project. Is this a completely ridiculous concern? (The answer may well be "yes," but I'd like to see a good argument why.)

Silhouette 11y ago
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.
- r2dnb 11y ago
  >Move fast and break things You made my day, I never heard of that one... unbelievable !
  - 11y ago

EvanPlaice 11y ago

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

EvanPlaice 11y ago
Not sure why this touched a nerve enough to be downvoted into oblivion. If it was the cheeky tl;dr I guess I can make a point to avoid any and all attempts at sarcasm in my future posts. As for the rest, I genuinely think it's a useful approach to consider 1. it's relies on future web standards not tools Tools come and go. Web standards never go. If the goal is to avoid technical debt, then don't write code in a way that will eventually be obsolete. 2. 'Abstractions are the solution to every problem, except the problem of too many abstractions' Except, when there's a viable strategy to provide access at multiple layers of abstraction. If we're finally getting a truly universal module standard, why not leverage it to improve our library APIs? It's not like we have to waste the time/energy/effort supporting multiple module non-standards anymore. The approach I outlined above provides much better usability with very little effort on the part of the dev implementing an API. 3. It doesn't rely on approaches that will eventually be obsolete Namely bundling. Tree shaking is great if the end goal is to analyze all dependencies and create an optimized bundle. Except for the fact that bundling will become an anti-pattern when HTTPv2 reaches widespread adoption.

bsimpson 11y ago

If tree-shaking is your jam, you'll be especially excited for Webpack 2: https://gist.github.com/sokra/27b24881210b56bbaff7 https://gist.github.com/sokra/27b24881210b56bbaff7

jordanlev 11y ago

I think the javascript ecosystem has a fundamental difference from all other languages/communites that came before it: it is universal. Hence I think a lot of the debates raging about the right tools come down to different people using it for different purposes. I doubt that everyone can consolidate on just one set of tools, because in javascript-land "everyone" means something different than other places. How can a tool that is good for a front-end designer who needs basic DOM manipulation also be the right tool for someone building an entire application in js and only using HTML as a delivery mechanism for their app bundle? I wish people would recognize in these discussions that their use-case might be different from others, and instead of talking about "the best tools", instead talk about "the best tools for this class of applications". So hopefully the toolset could be consolidated down to one clear choice for each class of usage. Then the biggest decision to make is deciding which type of application it is you're building.

davedx 11y ago
This is definitely part of it. JavaScript tooling encompasses back end, front end (progressive enhancement inside server generated web pages), front end (large single page apps), and a bunch of language flavours (ES5, ES6, ES7, TypeScript, JSX, to name a few). So it's understandable the tooling ecosystem is large and diverse, and that plumbing it all together can result in premature hair loss. We're using ES5 with AngularJS at work, and it's like a breath of fresh air ;)

mdavidn 11y ago

Interesting how the industry has come full circle. Static linking and dead code elimination is a problem we solved in the 1970s for compiled languages. Has the time come to adopt a proper linker for the web? Google's Closure Compiler has supported dead code elimination [1] since 2009, but the feature imposes some unpalatable restrictions. It never supported popular libraries like jQuery. The process is also rather slow, as Closure Compiler must analyze all code in the bundle at once. [1]: https://developers.google.com/closure/compiler/docs/compilation_levels#advanced_optimizations https://developers.google.com/closure/compiler/docs/compilat...

virmundi 11y ago
An interesting thing is how that applies to transpiled languages like ClojureScript. There are a lot of efficiencies gained by using ClojureScript with Google Closure. Even react is faster with Reagent.

szines 11y ago

I’ve been using ES6 modules in Ember.js development for two years now. Using Ember CLI is simplified down the dev process extreamly. The whole dev app development is so simple and fun with Ember. I don’t understand why people cry about it, the solution is exist, they should just use it. Thats all.

napperjabber 11y ago

One of the major differences between a jr and a sr IMO, is their ability to tell you what each one of those dependencies solves. If they don't know the sub-dependencies by heart, they didn't read the code or at least look it up outside of understanding the API. Than you have the maintenance developer, and everyone loves 'em. He just figures things out and helps you improve your code while you scream at him for not knowing the 'bigger picture'. Fun times.

justaaron 11y ago

One should consider the possibility that the entire web development industry is a giant busy-work factory making half-baked kluges to a fundamental problem that will never be papered over: http is a stateless protocol for sending hypertext. markup. meta-data and context for resources in a folder somewhere. It's a file-system thing. A web browser is a declarative-markup-tree rendering-engine with scriptable nodes, and the language chosen for scripting is an accident of history. Using http and web browsers in ways they never were intended to be used is possible, albeit painful. Now that we have virtual DOM's and isomorphic platforms like clojure/clojurescript and we compile to JS, now that we have JS on the server, now that we have our head so thoroughly up our ass that we forgot the point, now we can consider the circle of ridiculous nonsense complete... The world wide web took off, and we have to live with it's technical debt, or... The solution is simple, bold, and risky: 1) pick a port. (Nowadays that's even a joke. we tunnel everything over port 80.) 2) pick a protocol with some future (hey let's just tack websockets on as an upgrade, gradually get browser support, etc) 3) keep moving... I am not ultra impressed with the web of 2016... The web of 1996 was way cooler. I want a VRML3 rendering engine for a browser.

justaaron 11y ago
Oh, don't even get me started with build tools. Nowadays we have build tools to build build tools. I'm sorry, but when FRONT-END DEV considers build tools standard we are LOST lost lost... How many JS libraries and CSS scripts do we really need to embed in a page? How many of those functions or classes are even being used in that page? Why do I have to scroll to view source on a page with mostly text and a few colored boxes? Hand-coded html and css is not that hard folks... it's just the habits, the frameworks, etc... 1/4 of the web is powered by Wordpress wtf!?
- justaaron 11y ago
  In a nutshell, I think, with some risk, that some innovators could literally pick a port, pick a protocol, and build a different kind of browser... once there is some content for that platform it's a matter of time before early adopters download one of these new class of browsers and so forth... it's how it happened the first time, and it's how pretty much everything happened... even games (second life) etc. and meanwhile, the web can go back to being a directory preview/ resource hyperlink web...