Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Controversial State of JavaScript Tooling

ponyfoo.com

Post reply on HN
Print view View original

61–70 of 160 posts

Re: The Controversial State of JavaScript Tooling

#61

Post by gedy »

pekk wrote: post #56
gedy wrote: post #39

Earlier quoted context omitted.

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.

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…

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!

Re: The Controversial State of JavaScript Tooling

#62

Post by xorcist »

alextgordon wrote: post #12

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

You might want to seek out actual numbers before you say that. More often than not, that particular cache entry is evicted because of the billion combinations of frameworks, versions and CDNs. You are very far from downloading 0 bytes even for the popular frameworks.

There's also the issue of availability. If you decide to use one, make sure to have local fallback. The one time I did some remote instrumentation on this, some users actually had trouble reaching the CDN. I have no idea why, it might have been DNS failures or routing problems or whatever, but that made the whole site freeze for those affected since there was no fallback.

Re: The Controversial State of JavaScript Tooling

#63

Post by EvanPlaice »

TimJYoung wrote: post #55

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 everyt…

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.

Re: The Controversial State of JavaScript Tooling

#64

Post by drhayes9 »

haberman wrote: post #50
drhayes9 wrote: post #49

Earlier quoted context omitted.

You make the thing you're requiring an "external", such that the bundler knows it's available somewhere but won't include it. Here's browserify's documentation about the matter: https://github.com/substack/node-browserify#external-require...

The doc you linked to describes how to create a bundle of JS that will export a "require()" function exposing the bundled libs to other JavaScript. That doesn't seem related to the question of how to create a bundle that assumes that some libs have already been loaded with a previous script tag that pulled, say, jQuery from a CDN.

Whoops! That's what I get for speed-linking.

I meant this one: https://github.com/substack/node-browserify#bexternalfile

For something like jQuery you might also need a browserify shim. And now we're edging closer into some of the stuff this essay decries.

Re: The Controversial State of JavaScript Tooling

#65

Post by taurath »

lhnz wrote: post #24

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…

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.

Re: The Controversial State of JavaScript Tooling

#66

Post by ssmoot »

anonyfox wrote: post #14
sotojuan wrote: post #7

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

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 a…

Maybe not worth much, but the one Ember app I use routinely (that I'm aware of) is YNAB. The startup is slow, the payload obscenely large (over 3MB) for basically 2 different views, a handful of modals. It has odd UI issues occasionally that appear related to data-binding of some sort (tabbing through a field will sometimes cause an associated modal to freak out). Plus the URLs are useless.

I don't know how much of that is Ember and how much is implementation, but I assume their developers are smart enough.

What value did Ember bring to the party? It seems to have made what appears to be a simple thing (at a high level; not that there isn't plenty of effort involved in little bells and whistles here and there), complex and slow.

For me it's like that old saying about Art. I may not know exactly what I'm seeing, but I know what I like, and that isn't it. When your framework has basically the goals as ASP.NET v1 but the code looks worse, that's a major step in the wrong direction. It's been over a decade. This doesn't feel like progress.

Re: The Controversial State of JavaScript Tooling

#67

Post by arohner »

alextgordon wrote: post #12

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

Your cache isn't as warm as you think it is. The cache on mobile browsers is ~50MB, and 250MB on IE11. It's smaller on older IEs. Most regular internet users will download more than that every single day.

You should always use a CDN, but that doesn't excuse large libraries.

Shameless plug, but my startup, https://rasterize.io can tell you your cache hit rate for every visitor to your site.

Re: The Controversial State of JavaScript Tooling

#68

Post by arohner »

stcredzero wrote: post #32

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

Re: The Controversial State of JavaScript Tooling

#69

Post by tyingq »

swanson wrote: 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 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.

Re: The Controversial State of JavaScript Tooling

#70

Post by arohner »

swanson wrote: 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.slideshare.net/devonauerswald/walmart-pagespeedsl... slide 37)

My own customers have seen 4x different conversion rate, when grouped by page load time. (i.e. same slide as walmart page 37 above, where the peak is 4x higher than the lowest performing group).

Your business probably won't fail because it's slow, but it will certainly make less money because it's slow.

Post reply on HN