The Controversial State of JavaScript Tooling • Hacker News Board

Re: The Controversial State of JavaScript Tooling

#21

Post by cshenoy » Tue, Feb 02, 2016, 6:21 PM UTC

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…

After working on a few large JS applications (using Backbone or Angular or React), I decided to try out Ember for a relatively smaller application.

Ember feels very Rails-y (likely on purpose) and the documentation wasn't great. It took me a few hours to get a surface level understanding of how things worked with each other, especially Ember Data. I ultimately ended up dropping it because of my frustration. It was only a couple months ago (early December 2015).

Obviously I'm just one data point but I know I've talked to other devs who feel the same way. I'm sure Ember will only get better but I don't think it's the antidote at all.

Re: The Controversial State of JavaScript Tooling

#22

Post by vosper » Tue, Feb 02, 2016, 6:21 PM UTC

dpkrjb wrote: post #17

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 believe the main problem with googles cdn is it can prevent Chinese users from visiting your site

I would imagine it's China that's preventing Chinese users from visiting your site, not Google?

Re: The Controversial State of JavaScript Tooling

#23

Post by ybx » Tue, Feb 02, 2016, 6:25 PM UTC

vosper wrote: post #22

dpkrjb wrote: post #17

Earlier quoted context omitted.

I believe the main problem with googles cdn is it can prevent Chinese users from visiting your site

I would imagine it's China that's preventing Chinese users from visiting your site, not Google?

Yes, but the end result is the same

Re: The Controversial State of JavaScript Tooling

#24

Post by lhnz » Tue, Feb 02, 2016, 6:25 PM UTC

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 practice modules have completely irrelevant names). There are thousands of buggy modules in which development has stalled, and it's easy to waste a lot of time trying to separate the wheat from the chaff. I personally sometimes have to open up 5+ Github repositories to check their last commit, number of contributors, interfaces, code quality, unanswered issues, etc. Only after doing so am I able to make a decision.

In terms of knowing what's cutting-edge practice it seems you have to watch Twitter a lot and be careful not to follow every single bad idea.

I can't imagine what it'll be like to search for a module to handle something as common as config in a couple of years. Even when you constrain yourself to something like '12 factor config' there are many different implementations.

Don't even get me started on the insane assembly required to get webpack-, babel-, cssmodules-, and postcss- to all work together.

The problem is only going to get worse.

Re: The Controversial State of JavaScript Tooling

#25

Post by realharo » Tue, Feb 02, 2016, 6:27 PM UTC

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…

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's a good tool when it works properly, but they really need to work on those rough edges a bit.

Re: The Controversial State of JavaScript Tooling

#26

Post by s986s » Tue, Feb 02, 2016, 6:29 PM UTC

swanson wrote: post #19

Are there any documented cases of a business failing because their JS payload was too large? I get that smaller code is easier to understand/work with, but I've never been able to internalize the desire for small payload -- just doesn't seem like it ever matters outside of philosophic reasons for saving user's bandwidth (especially if it comes with a steep tooling cost). It strikes me as a technical pursuit in search…

Site loading speed is very important

https://blog.kissmetrics.com/loading-time/

Re: The Controversial State of JavaScript Tooling

#27

Post by LewisJEllis » Tue, Feb 02, 2016, 6:31 PM UTC

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…

Sure, if someone's not using a popular 3rd party CDN because they don't know the option exists or they don't understand the potential benefits, then yes, consideration should be given. They're not always the answer, though, and there are plenty of legitimate business and security reasons why one might prefer to host their own dependencies.

Sometimes technical reasons make the potential benefit minimal, anyway. Once someone's already making one request for your application source, adding a bit more to that response (a bundled minimum-necessary-subset of some not-massive dependency) can make only a very minor performance difference. It won't be as fast as if a file containing the entire dependency was in the browser's cache (or possibly even in the JS engine's compilation cache), but it'll be significantly faster than if it wasn't.

Re: The Controversial State of JavaScript Tooling

#28

Post by alextgordon » Tue, Feb 02, 2016, 6:32 PM UTC

dpkrjb wrote: post #17

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 believe the main problem with googles cdn is it can prevent Chinese users from visiting your site

I guess, but if you go to the trouble of localising your website into Chinese, then loading a self-hosted version of the library for Chinese users doesn't seem like much extra work.

Re: The Controversial State of JavaScript Tooling

#29

Post by rickboyce » Tue, Feb 02, 2016, 6:33 PM UTC

swanson wrote: post #19

Are there any documented cases of a business failing because their JS payload was too large? I get that smaller code is easier to understand/work with, but I've never been able to internalize the desire for small payload -- just doesn't seem like it ever matters outside of philosophic reasons for saving user's bandwidth (especially if it comes with a steep tooling cost). It strikes me as a technical pursuit in search…

I think there are circumstances where it is very valuable - it depends on your target audience.

For example on mobile, connection speeds in major cities in developed countries maybe rocketing, but substantial areas still need to make a lot happen with very little bandwidth. So it can be a small competitive advantage.

Re: The Controversial State of JavaScript Tooling

#30

Post by ktRolster » Tue, Feb 02, 2016, 6:34 PM UTC

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.