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

51–60 of 160 posts

Re: The Controversial State of JavaScript Tooling

#51

Post by dsp1234 »

s986s wrote: post #38
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…

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.

Re: The Controversial State of JavaScript Tooling

#53

Post by __derek__ »

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

Re: The Controversial State of JavaScript Tooling

#54

Post by mutagen »

citricsquid wrote: post #36
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 was an article in recent memory that looked at how various websites were using CDN's for delivering common libraries and if I recall correctly they concluded that the chance of getting a cache hit from a CDN is relatively low because of the different versions each website is using. The Google CDN for example offers dozens and dozens of different versions of jQuery: your visitor might have visited a site using j…

I'm only aware of this slightly older (11/2011) article [1] on the topic. I've poked at the numbers recently in Big Query and see a wide spread for jQuery versions on popular sites. Maybe one of these days I'll get around to documenting it properly. I'd rather measure from a sampling of client side pageloads but this might be a bigger project to tackle.

[1] http://statichtml.com/2011/google-ajax-libraries-caching.htm...

[2] http://stackoverflow.com/questions/29930805/measuring-visito...

Re: The Controversial State of JavaScript Tooling

#55

Post by TimJYoung »

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 everything is given away for free and there are no barriers to entry, you'll keep ending up with chaos and unmanageable churn whereby your job as a software developer has now morphed into a software tester/evaluator for every single piece of functionality that you need and don't want to write yourself.

When you have to actually put your money on the line and have an actual business presence on the web, it's a completely different mindset from "I'm going to write this small library and pop it up on GitHub for free, so who cares if there's documentation or if the software even works as described". The fact that there are developers that are professional and thorough and still give away their software is a minor miracle. But, it's not wise to count on the charity of such developers for the long-term because it isn't realistic. As more and more one-offs are created, it becomes much harder to distinguish one's software from the rest of the pack, so developers will simply not even attempt to do so. The Apple store is a perfect example of this problem.

Re: The Controversial State of JavaScript Tooling

#56

Post by pekk »

gedy wrote: post #39
ktRolster wrote: post #30

Earlier quoted context omitted.

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

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 actually gone backwards in terms of ideas like "semantic markup" and most websites are no longer fit for viewing in Lynx. Which also means accessibility has gotten worse. Bloat is worse than ever and privacy issues are worse than ever. Power over the internet is concentrated in the hands of huge corporations who run crummy walled gardens. At least in the 90s most internet users agreed that AOL's walled garden was a bad idea, but now everyone comes out of the woodwork to argue in favor of Facebook or the App Store. I'd say things are worse than before.

Re: The Controversial State of JavaScript Tooling

#57

Post by __derek__ »

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…

It seems to me that most of the people complaining have been from the web old-guard (e.g., PPK[1][2]), but maybe I've missed the "kids" who are complaining.

[1]: "Stop pushing the web forward" http://www.quirksmode.org/blog/archives/2015/07/stop_pushing...

[2]: "Tools don’t solve the web’s problems, they ARE the problem" http://www.quirksmode.org/blog/archives/2015/05/tools_dont_s...

Re: The Controversial State of JavaScript Tooling

#58

Post by chipotle_coyote »

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 of other projects, our work now has the potential to be affected by the technical debt -- bugs, poor optimizations, whatever -- in the underlying projects.

Obviously, this has always been true to varying degrees. 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.

I don't want to suggest we should be writing everything from scratch and constantly re-inventing wheels, but when even modest applications end up with hundreds of subdirectories in their local "node_modules" directory, it's hard not to wonder whether we're making things a little...fragile, even taking into account that many of those modules are related and form part of the same pseudo-modular project. Is this a completely ridiculous concern? (The answer may well be "yes," but I'd like to see a good argument why.)

Re: The Controversial State of JavaScript Tooling

#59

Post by EvanPlaice »

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

This is talking specifically about an optimization problem. How to minimize source size by only inporting code that is used directly in the appplication.

AFAIK, no other platforms don't attempt to solve this problem because it's a non-issue except where you're sending code over a network to be executed remotely.

For example, imagine if you had to send the entire Java Runtime Environment over the wire every time you loaded a website.

Re: The Controversial State of JavaScript Tooling

#60

Post by baldfat »

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…

Creating something is difficult and criticizing is easy. Such that showing oneself to be capable by creating is MUCH harder then showing oneself to be capable by criticism.
Post reply on HN