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

141–150 of 160 posts

Re: The Controversial State of JavaScript Tooling

#141

Post by erikpukinskis »

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…

Basically, you look at the project's social presence.

That sounds kind of airy-fairy, but it's honestly how it works. You look at what the README says, how well it addresses questions, you look at the release history, see how maintainers interact with contributors, read a blog post or two to see how the maintainers are thinking.

And then you make a judgement call.

You don't have to get it right every time. That's the beauty of the modular approach. If you get it wrong, then you're smarter when you go to replace that piece of the infrastructure.

Re: The Controversial State of JavaScript Tooling

#142

Post by paulirish »

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…

I've worked on the Google JS library CDN for a few years now. Our data indicates that cache hit rates are very low. You'd be better off serving jQuery from your libs.min.js.

In general, browser caches fill up so fast and there are so many versions of jQuery in use in the wild, that the cache never ends up being as useful as we'd hope. Sorry. :/

Re: The Controversial State of JavaScript Tooling

#143

Post by [deleted] »

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.

[deleted]

Re: The Controversial State of JavaScript Tooling

#144

Post by erikpukinskis »

paulirish wrote: post #142
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…

I've worked on the Google JS library CDN for a few years now. Our data indicates that cache hit rates are very low. You'd be better off serving jQuery from your libs.min.js. In general, browser caches fill up so fast and there are so many versions of jQuery in use in the wild, that the cache never ends up being as useful as we'd hope. Sorry. :/

You need "LTS" releases of libraries and clients which auto-update to the newest point release on the LTS branch before this will work.

Although, that's the right direction for package management to go anyway, so we might as well.

Re: The Controversial State of JavaScript Tooling

#145

Post by napperjabber »

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.

Re: The Controversial State of JavaScript Tooling

#146

Post by chc »

soft_dev_person wrote: post #139
Touche wrote: post #95

Earlier quoted context omitted.

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

It's a bit ironic to praise Microsoft for stability in this context, when they probably have had a major role of causing instability in the web front-end world for more than a decade.

I thought most people's complaint was that Microsoft caused stagnation, not instability. Explorer was too stable for most developers' tastes.

Re: The Controversial State of JavaScript Tooling

#147

Post by colllectorof »

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…

The difference is that we've seen that the other kind of web development (without grapevines of libraries and complex toolchains) is both possible and capable of producing usable results. We're regressing.

Re: The Controversial State of JavaScript Tooling

#148

Post by lmm »

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…

> But hey, at least we can centre things vertically in CSS with Flexbox now

You mean we're back up to feature parity with when we used tables for layout? Awesome!

Re: The Controversial State of JavaScript Tooling

#149

Post by colllectorof »

gedy wrote: post #61
pekk wrote: post #56

Earlier quoted context omitted.

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!

> It was a huge hurdle just to do pretty much anything beyond display text documents

Like what?

The trend I see in practice is that most web applications are still 98% text documents with images, but a combination of modern design patterns and tooling makes generating those documents insanely complicated.

Currently I'm watching a project to "modernize" a bunch of small websites. The amount of effort it takes to convert them to some "familiar" (Bootstrap-like) UI is cringe-worthy.

Re: The Controversial State of JavaScript Tooling

#150

Post by d215 »

chc wrote: post #146
soft_dev_person wrote: post #139

Earlier quoted context omitted.

It's a bit ironic to praise Microsoft for stability in this context, when they probably have had a major role of causing instability in the web front-end world for more than a decade.

I thought most people's complaint was that Microsoft caused stagnation, not instability. Explorer was too stable for most developers' tastes.

Most people's complaint was Microsoft was trying to push their own proprietary standards (Activex anyone?) upon the www at large. Also their adherence to Web standards at the time IE6 came out was so bad, that it caused almost unsurmountable instability.
Post reply on HN