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

31–40 of 160 posts

Re: The Controversial State of JavaScript Tooling

#31

Post by orf »

anonyfox wrote: post #14
sotojuan wrote: post #7

It's interesting how none of the JS/tooling fatigue discussions mention Ember, which has one public-facing tool.

So true. Ember is the antidote right now for the frontend land. - MVC (Backbone's big thing) - Two way binding (Angular's big thing) - Components (React's big thing) - SSR like the others now (FastBoot) - High performance with the Glimmer Engine (should beat react in theory) - Books. - dedicated package repository (emberaddons) - actually community driven - stable + mature (+ seamless upgrade paths) - and many more a…

I feel the same. I love Ember, it's the first proper frontend framework and boy is it frustrating at the start. Once you get past that though it's plain sailing and takes my productivity to a whole new league.

It's just not mentioned... anywhere. It's not hip like React or has a big sponsor like Angular I guess. But I don't get it, it's really really good.

Re: The Controversial State of JavaScript Tooling

#32

Post by stcredzero »

> 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 was already tried and what the problems were. Chances are, it was already tried, and that there's useful experiential data there.

Re: The Controversial State of JavaScript Tooling

#33

Post by orf »

realharo wrote: post #25
anonyfox wrote: post #14

Earlier quoted context omitted.

So true. Ember is the antidote right now for the frontend land. - MVC (Backbone's big thing) - Two way binding (Angular's big thing) - Components (React's big thing) - SSR like the others now (FastBoot) - High performance with the Glimmer Engine (should beat react in theory) - Books. - dedicated package repository (emberaddons) - actually community driven - stable + mature (+ seamless upgrade paths) - and many more a…

Last time I had to use ember (about 2 months ago), the ember-cli tool had major performance issues. I remember rebuilds after a single line of code was changed taking almost 10 seconds. It also generated almost 10 gigabytes of temporary files over time. Plus I remember an issue with import paths not matching real filesystem paths, which was messing with my IDE (and my brain until I figured out what was going on). It'…

> I remember rebuilds after a single line of code was changed taking almost 10 seconds.

Do you happen to be on Windows? My Ubuntu laptop compiles changes to our pretty large app in under a second, but on Windows it does take up to 10 seconds.

Re: The Controversial State of JavaScript Tooling

#34

Post by rapind »

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 to apps that are meant to work offline, although I think this is solved with service workers proxying the CDN request.

And if the recommendation is to continue loading large libraries from a CDN and nevermind only what you need, well there's still a memory cost. If I have 5+ SPAs running in tabs that are each fairly complex (you know, like Gmail), it does start to add up. Because of the way that tabs are sandboxed I believe this may mean 5 copies of jQuery or React or Angular or w/e.

Re: The Controversial State of JavaScript Tooling

#35

Post by LewisJEllis »

atemerev wrote: post #15

Babel got it wrong. Hypermodularisation is a good thing in user-facing code. Here we should thrive to shave off every last byte. But Babel is a tool for developers. We don't need configuration explosion and endless plugins. We need all batteries included. The very purpose of Babel is "hey, I want to write hip code like the rest of cool kids of the block; now, let it run everywhere". Who needs to configure that?

I agree that Babel doesn't get every single thing right, in much the same way that everything manages to get something wrong, but I don't think you're giving credit to the benefits of its modularity.

Another "purpose" of babel is "hey, I want to implement an upcoming ECMAScript feature in an extensible and relatively self-contained way so I don't have to go digging deep inside someone's codebase."

Or, it's also "hey, I only need these 3 features and I want my build times to stay as low as possible."

For the use case you describe, there are presets provided to make that quite simple.

Re: The Controversial State of JavaScript Tooling

#36

Post by citricsquid »

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 jQuery before, but have they visited a site using the same version? Unfortunately I cannot find the article, maybe someone else will be able to provide a link.

There are other concerns too, if your website depends on a Javascript library and the CDN is offline it can break your website (which has happened with Google CDN before, and many of the other popular Javascript CDN's). What if the CDN is compromised and is delivering malicious content? Not impossible.

Re: The Controversial State of JavaScript Tooling

#37

Post by mutagen »

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…

Version fragmentation pushes the CDN hit rate down quite a bit. Unless you're using the exact major/minor version that some popular sites are using you're going to see high miss rates, especially on mobile where it likely matters the most.

Re: The Controversial State of JavaScript Tooling

#38

Post by s986s »

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 bringing the best to such a widely used language, mobile phones frameworks and compilers, microsoft, google, apple, unity, mozilla.

Javascript is the real deal. What makes it crazier is that 10 year olds can do a few tutorials on html5 rocks and feel confident in their abilities (in a good way). Javascript is not just a crappy language, there a socio-political aspect that has probably never been seen before

Re: The Controversial State of JavaScript Tooling

#39

Post by gedy »

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.

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.

Re: The Controversial State of JavaScript Tooling

#40

Post by realharo »

orf wrote: post #33
realharo wrote: post #25

Earlier quoted context omitted.

Last time I had to use ember (about 2 months ago), the ember-cli tool had major performance issues. I remember rebuilds after a single line of code was changed taking almost 10 seconds. It also generated almost 10 gigabytes of temporary files over time. Plus I remember an issue with import paths not matching real filesystem paths, which was messing with my IDE (and my brain until I figured out what was going on). It'…

> I remember rebuilds after a single line of code was changed taking almost 10 seconds. Do you happen to be on Windows? My Ubuntu laptop compiles changes to our pretty large app in under a second, but on Windows it does take up to 10 seconds.

Yes, it was a Windows machine. I did all the "make it faster" steps, like running the recommended script that adjusts Windows Defender and search indexing configuration, but in the end it was still very slow, even on a fairly fast SSD.
Post reply on HN