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

111–120 of 160 posts

Re: The Controversial State of JavaScript Tooling

#111

Post by [deleted] »

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…

[deleted]

Re: The Controversial State of JavaScript Tooling

#112

Post by hatsix »

realharo wrote: post #40
orf wrote: post #33

Earlier quoted context omitted.

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

There are several teams at MS using ember (and ember-cli), and they've been PR'ing improvements. (Source: MS hosted the last Seattle Ember Meetup: http://www.meetup.com/Ember-js-Seattle-Meetup/events/2278796...)

What helped me the most was moving to Node 4+, which made memory management MUCH better.

Re: The Controversial State of JavaScript Tooling

#113

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

#114

Post by auvrw »

sotojuan wrote: post #7

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

tried to use ember-cli w/o enforcing some certain opinions (e.g. directory structure) on a project and reached out to the community via slack, but it hasn't really taken so far.

maybe Goya was a bad choice? someone on the slack used the term "consume" for what i was trying to do w/ ember-cli, and..

https://github.com/ransomw/ember-cli-programmatic-usage

Re: The Controversial State of JavaScript Tooling

#115

Post by wwweston »

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…

> 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 one of these, it seems to me, is likely to be consistently related to the quality of the module.

Re: The Controversial State of JavaScript Tooling

#116

Post by aikah »

TimJYoung wrote: post #91
aikah wrote: post #84

Earlier quoted context omitted.

People use github because it's free hosting first and foremost. 99% of projects on github are never fetched or forked by third parties, let alone maintained, so i'm not sure about what you're complaining about. Are you complaining about people publishing crap on free hosting ? nobody forces you to use all that code.

I'm not complaining about anything. I'm trying to put forth a reason for why so many other developers are complaining about the constant churn in the JS tools ecosystem, and the immense amount of setup required to do even simple web apps. Judging by the downvotes, I'm guessing my opinions aren't very popular or I strayed too far off-topic. :-)

> and the immense amount of setup required to do even simple web apps.

This complexity is sold by people who are selling complex tools. I don't use Babel or Webpack because it is not necessary. I usually try to remain framework free or use a framework that has a minimal complexity cost. You can write a complex application with jQuery , Angular 1.0 or Vue.js or even React in ES5 and it will not require any complex asset pipeline + build tool + 50 plugins in order to get started.

As said earlier, in my opinion the only tools worth using are Typescript compiler and Bower for package management. I discarded everything else because I just don't want to spend my time in configuration files, it doesn't solve my issues or my client's issues. It's exactly like in the enterprise world in that aspect, where vendors try to sell businesses useless and complex solutions that will eventually get discarded when the insane cost becomes too apparent.

Re: The Controversial State of JavaScript Tooling

#117

Post by darkmarmot »

freshyill wrote: post #106
bshimmin wrote: post #98

Earlier quoted context omitted.

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

I love flexbox (compared to what existed prior) -- but just watched layouts break on the release of Chrome 48. Yay! :)

Re: The Controversial State of JavaScript Tooling

#118

Post by skybrian »

stcredzero wrote: post #32

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

I agree, it only works when you're not too dynamic. Smalltalk wasn't designed that way.

You need a compiler that can tell when thing A requires thing B at a fine-grained level. That often requires type declarations, or at least fairly unique function names.

You also need library owners to design with tree-shaking in mind, so that calling library function A doesn't automatically pull in library function B. You need sane dependencies.

You also need dependency injection (if you have it) implemented in a way that doesn't defeat tree-shaking.

GWT, Closure, and Dart all do this by not being too dynamic (most of the time). In particular, reflection and tree-shaking don't work well together.

Re: The Controversial State of JavaScript Tooling

#119

Post by RaleyField »

hassy wrote: post #109
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…

> all the way down to the kernel

There was a bug that allowed you to go to SMM. The fun doesn't stop with the kernel.

Re: The Controversial State of JavaScript Tooling

#120

Post by skewart »

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…

As others have pointed out, the number of lines of code that the typical 2016 webapp depends on isn't all that different from other ecosystems. The dependency footprint just looks a lot bigger because its broken up into lots and lots of little modules.

I'd argue this actually makes things a little less fragile, because - at least theoretically - its easier to manage versions and do rollbacks of the different various pieces if something goes wrong. You can surgically switch the version of a dependency without necessarily changing a lot of other functionality.

Of course, things aren't always that simple. And lots of little modules might effectively mean less integration testing and higher chances of bugs. So, maybe it's a toss-up.

Post reply on HN