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

101–110 of 160 posts

Re: The Controversial State of JavaScript Tooling

#101

Post by jordanlev »

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.

Re: The Controversial State of JavaScript Tooling

#102

Post by mateo411 »

rapind wrote: post #34
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…

There are quite a few disadvantages to using a CDN like Google. - Delay for DNS resolution and the new TCP connection could be non-trivial (some tests show 300ms+). - A JS CDN is also likely tracking your traffic and you may not want them to. - No offline dev environment (on the plane). - Server run (phantom etc.) tests might run super slow if they have to pull in a remote js library. - Probably issues when it comes…

It's possible to not use the CDN when you are developing in your local environment, and use the CDN in your production environment. That way you can keep developing even when you are on an airplane.

Re: The Controversial State of JavaScript Tooling

#103

Post by nommm-nommm »

ktRolster wrote: post #30
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…

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

The web is fantastic today compared to what it was when I started web development a decade ago.

Re: The Controversial State of JavaScript Tooling

#104

Post by chipotle_coyote »

gotchange wrote: post #97
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 t…

You might be right. From exploring other open source applications my impression is that there tends to be many times more external libraries, tools and plugins pulled in by modern web applications when compared to, say, a Cocoa/Objective-C application of moderate size, though.

Re: The Controversial State of JavaScript Tooling

#105

Post by edejong »

rapind wrote: post #34
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…

There are quite a few disadvantages to using a CDN like Google. - Delay for DNS resolution and the new TCP connection could be non-trivial (some tests show 300ms+). - A JS CDN is also likely tracking your traffic and you may not want them to. - No offline dev environment (on the plane). - Server run (phantom etc.) tests might run super slow if they have to pull in a remote js library. - Probably issues when it comes…

Plus the cost of parsing the JSON and merging the huge object structures these libraries provide.

I missed one item on your list, which is security. Google does not provide any guarantees on the safety of the CDN provider versions of JQuery. Imagine the mayhem when a widely used jquery library is replaced by a backdoored version.

Re: The Controversial State of JavaScript Tooling

#106

Post by freshyill »

bshimmin wrote: post #98
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…

Flexbox took forever to arrive, but I its defense, support is at 95% these days.

http://caniuse.com/#feat=flexbox

Re: The Controversial State of JavaScript Tooling

#107

Post by cgh »

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…

Python and gcc are free software too. Lots of stability in the world of Python and C. Hopefully you don't think free or open source software is somehow limited to the world of Javascript.

Here's why there is so much churn in the JS world: everyone is attempting to polish a turd.

Re: The Controversial State of JavaScript Tooling

#108

Post by andrewingram »

r2dnb wrote: post #87
Silhouette wrote: post #79

Earlier quoted context omitted.

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 !

It was Facebook's motto for a long time.

Re: The Controversial State of JavaScript Tooling

#109

Post by hassy »

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…

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

Um, take ANY non-trivial application, written in any language, and then follow the chain of its dependencies all the way down to the kernel, and shriek in horror. JS is not unique here, the only unique part is perhaps how obvious npm makes it just how much stuff your code depends on.

Re: The Controversial State of JavaScript Tooling

#110

Post by lr4444lr »

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 you make some good points, as do a number of your repliers. We're pulled in different directions by a number of business and technical priorities. What I see as a common denominator is a development life-cycle that expects increasingly nimble articulation of break-off projects and shorter iteration times into production, at least in SaaS. Concerns about code stability and optimization are not entirely lost by any means, but they don't seem to have the same priority when the business "has to" keep moving, and the tech "has to" keep evolving at this pace.
Post reply on HN