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

91–100 of 160 posts

Re: The Controversial State of JavaScript Tooling

#91

Post by TimJYoung »

aikah wrote: post #84
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.

I'm not complaining about anything. I'm trying to put forth a reason for why so many other developers are complaining about the constant churn in the JS tools ecosystem, and the immense amount of setup required to do even simple web apps. Judging by the downvotes, I'm guessing my opinions aren't very popular or I strayed too far off-topic. :-)

Re: The Controversial State of JavaScript Tooling

#92

Post by stcredzero »

arohner wrote: post #68
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.

Google Closure has been successfully tree-shaking since it was released, in 2009

One can still write code that breaks the tree-shaking. How does Google Closure solve that? Through its community and best practices. Arguably, this is where Smalltalk failed, and where other dynamic languages can take a useful lesson. (Being fostered by an environment like Google probably gave Closure a leg up this way.)

ClojureScript uses Closure for an optimization path

ClojureScript has an advantage, in that it's probably designed to not-easily produce code that breaks tree shaking.

Re: The Controversial State of JavaScript Tooling

#93

Post by arohner »

draw_down wrote: post #82
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…

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.

Depends on your connection. I gave a talk about CLJS page speed, and server side rendering at the recent Clojure conj (https://www.youtube.com/watch?v=fICC26GGBpg). Trying to load my site on the conference wifi, 200kB took 3 seconds = 60kB/s, so 30kB would have been enough.

"Ok, that's not real world". Today, the cable guy is here fixing my home internet, so I'm tethering my iPhone 5s. Loading the .js for my site took 40kB in 143ms = 300kB/s, so 150kB would have been enough.

"Still not real world". Fine. Here's the waterfall graph of a visitor from Canada to rasterize.io today: (https://s3.amazonaws.com/static.rasterize.com/canada-waterfa...). Loading the .js took took 40kB in 60ms = 666kB/s, so 300kB.

So certainly less than half a meg of JS, which is very common to see in SPAs.

Certainly, there are tons of other things that can slow down a site. But the JS is one of the "easiest" to solve, because devs are responsible for it, and it has well known solutions, that people don't apply consistently. (reduce dependencies, only serve one file, Use webpack/closure, use CDN)

Re: The Controversial State of JavaScript Tooling

#94

Post by arohner »

haberman wrote: post #46
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…

How can you use a CDN if you're also using a bundler/minifier? Put another way, how can you bundle your app such that CDN-available libs are "dynamically linked" but your app and less common libs are "statically linked"?

You can always upload the .js files to your own CDN.

The other magic of CDNs (aside from the potential cache reuse that everyone is talking about in this thead) is that the user downloads files from a geographically closer server to them than your server. This is typically a huge speed up, and applies even if your JS files are 100% unique.

Re: The Controversial State of JavaScript Tooling

#95

Post by Touche »

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…

More simply put, stability is not valued in the front-end world.

It's interesting to compare the dominance of Microsoft in the enterprise world where IT runs the show was established largely due to stability. IT is run by managers who can get fired if instability costs the company money.

In the front-end world managers can't keep up with the changing landscape and therefore cannot make stability based decisions (in terms of software stability). Instead, in my experience, they make decisions based on how easy it is to hire (as cheap as possible) developers.

So, as a proxy, popularity drives the front-end because developers who have the time to keep up with the latest trends (IE mostly young 20-somethings) because they're the ones who get hired.

Re: The Controversial State of JavaScript Tooling

#96

Post by extrapickles »

Lazare wrote: post #75
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…

> If you use Google CDN, why does it matter how big jQuery is? 1. Most people won't have the version you wanted to use cached from the location you were trying to use it from. Studies show hit rates on requests for libraries on "shared" CDNs are very low in real world conditions. (Also, caches are small. Oh, you wanted 2.3.4r17 of BigLib? I've only got 2.3.4r18 cached; I'll go ahead and delete that so I have room to…

To put some numbers to this, lets assume the user has a 1mbit connection with 300ms latency.

If a library is 32kb (on the wire) it will take 256ms to transmit to the client. If its not inlined, it would take 556ms to transmit, or almost twice as long for the cold cache case.

If the client has a 10mbit connection (average cheap 4g mobile connection), with the same latency, its even worse as the 32kb library now takes ~27ms to download if inlined and 327ms if not. This is now a order of magnitude slower.

With a latency of 100ms (typical home internet), its still 127ms to download the cold cache vs the 27ms inline takes.

Since connection bandwidth is slowly rising, it makes CDN library distribution a even worse idea as time passes. The speed of light (in copper/fiber) is the dominating factor in 100ms latency, so it will not be much improved without massive expense. It may even get to the point where inlining the library is faster than waiting for a cheap mobile device to fetch the cached copy out of flash.

Re: The Controversial State of JavaScript Tooling

#97

Post by gotchange »

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…

How's web development any different from other "branches" of software development when it comes to technical debt or deep dependency trees?!

It's been the norm in the field of software development since the early days to rely on other people's work for productivity reasons and many other objectives and consequently the trade-off of convenience with technical debt whether in implicit or explicit terms. I don't think that web development is more guilty of this "sin" than any other branch of the field.

Re: The Controversial State of JavaScript Tooling

#98

Post by bshimmin »

hodwik wrote: post #4

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…

I don't think I agree. I've been developing stuff for the web since the mid-90s, when TABLEs were just about starting to be a thing and Perl was definitely the preferred choice on the server. There has been plenty of excitement along the way, undeniably, but it feels like HTML5 took forever to get to where Flash was, JavaScript on the server still underwhelms me, and it seems almost daily to get more complex and full of enterprise beans, browsers are far from equal, the CSS3 spec isn't finished, developing for the mobile web is often a pretty wretched experience... and my clients still ask me to make their logos bigger and complain that important stuff is below the fold. Am I jaded? You bet.

But hey, at least we can centre things vertically in CSS with Flexbox now (apart from the dubious browser support, of course).

Re: The Controversial State of JavaScript Tooling

#99

Post by mlvljr »

dsp1234 wrote: post #51
s986s wrote: post #38

Earlier quoted context omitted.

This is different though. Javascript is something that all of us are, in one way or another, exposed to. Giant companies building an ecommerce platform, startups making fun and innovative spas, designers adding a bit of animation and adaptivity to a theme, bare metsl devs bringing javascript to robotics and operating systems, severside crud applications and websocket handling, C++ devs that are interesting in bringin…

10 year olds can probably never been seen before I sometimes feel that everyone thinks that this stuff is totally unique. However, I remember copying Basic code out of magazines and BBSs as a kid. Copying and modifying that code was as empowering and amazing then as github/npm/etc is now. There is certainly a higher quantity due to the ubiquity of the Internet, but the basic quality is the same.

Now, try to pull this argument off in a RPi thread... :)

Re: The Controversial State of JavaScript Tooling

#100

Post by s986s »

dsp1234 wrote: post #51
s986s wrote: post #38

Earlier quoted context omitted.

This is different though. Javascript is something that all of us are, in one way or another, exposed to. Giant companies building an ecommerce platform, startups making fun and innovative spas, designers adding a bit of animation and adaptivity to a theme, bare metsl devs bringing javascript to robotics and operating systems, severside crud applications and websocket handling, C++ devs that are interesting in bringin…

10 year olds can probably never been seen before I sometimes feel that everyone thinks that this stuff is totally unique. However, I remember copying Basic code out of magazines and BBSs as a kid. Copying and modifying that code was as empowering and amazing then as github/npm/etc is now. There is certainly a higher quantity due to the ubiquity of the Internet, but the basic quality is the same.

I suppose this is my generations basic : / Visual basic was my first language actually. It was pretty fun, built some cool stuff with it. I guess the web more free since people a share with and I dont need windows computers. And I dont need visual studio to make an application. When I first started with website dev I used to write in notepad because I didnt have the money for dreamweaver and I felt like I was joining the elite. Then I learned about notepad++ anf it felt like a very natural progression
Post reply on HN