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

81–90 of 160 posts

Re: The Controversial State of JavaScript Tooling

#81

Post by arohner »

robocat wrote: post #78
arohner wrote: post #70

Earlier quoted context omitted.

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!

I agree there's certainly some correlation, but we can fix e.g. "slow connections" and "slow computers" by not serving 9MB auto-playing hero videos [edit:] when it's not appropriate for your user demographics.

I'm not in the position to intentionally slow down my customers, so I haven't run a controlled test. Google's test was controlled though.

Re: The Controversial State of JavaScript Tooling

#82

Post by draw_down »

arohner wrote: post #70
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.slid…

But in this context, the issue becomes how much JS bundle weight it takes to cause a 0.5 second delay. And there are many other things that can slow down page load time (and especially perceived page load time) that either don't involve JS at all, or are not directly caused by the amount of JS that gets loaded.

Re: The Controversial State of JavaScript Tooling

#83

Post by xirdstl »

__derek__ wrote: post #53
haberman wrote: post #43

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…

I don't know if I'm missing something, but why not use Karma?[1] It includes Jasmine support out of the box, lets you run tests in PhantomJS, and offers a CLI to make project initialization pretty simple. [1]: https://www.npmjs.com/package/karma

This is what we use also. karma + jasmine + phantomjs. Admittedly, when we first started, I really did not understand which each of those individual pieces were.

Re: The Controversial State of JavaScript Tooling

#84

Post by aikah »

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…

People use github because it's free hosting first and foremost. 99% of projects on github are never fetched or forked by third parties, let alone maintained, so i'm not sure about what you're complaining about. Are you complaining about people publishing crap on free hosting ? nobody forces you to use all that code.

Re: The Controversial State of JavaScript Tooling

#85

Post by chrisoakman »

Silhouette wrote: post #77
arohner wrote: post #68

Earlier quoted context omitted.

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.

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 :)

Re: The Controversial State of JavaScript Tooling

#87

Post by r2dnb »

Silhouette wrote: post #79
chipotle_coyote wrote: post #58

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

>Move fast and break things You made my day, I never heard of that one... unbelievable !

Re: The Controversial State of JavaScript Tooling

#88

Post by TimJYoung »

EvanPlaice wrote: post #63
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 a…

The problem is that darwinism keeps biting us in the ass. It simply is not a recipe for orderly transitions between older and newer technologies, which ends up costing companies more, not less. One of the primary issues is always: who wants to work for free on software that is 10-15 years old ? Nobody. So, unless the software finds a sponsor of some sort that is willing to pay developers to fix bugs, make incremental improvements, and other very non-glamorous chores, it's going to languish as soon as it falls out of fashion and/or the primary developers move on to something else. And, what small company that is not in the developer tools business is going to want to finance the ongoing cost of keeping such software working ? Not very many.

I'm not saying that OSS shouldn't exist. What I'm saying is that OSS has serious effects upon how software is developed, and I don't think that these effects were taken as seriously has they should have been. Everyone saw "free", and it was game-over. There's a lot of good with OSS, but there was also a lot of good with commercial software that we seem to want to ignore. One of those good things was more stability.

Re: The Controversial State of JavaScript Tooling

#89

Post by wvenable »

EvanPlaice wrote: post #59
gsmethells wrote: post #45

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

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

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.

Re: The Controversial State of JavaScript Tooling

#90

Post by arohner »

Silhouette wrote: post #77
arohner wrote: post #68

Earlier quoted context omitted.

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.

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.

Post reply on HN