Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Hitchhiker's Guide to Modern JavaScript Tooling

reactkungfu.com

Post reply on HN
Print view View original

91–100 of 120 posts

Re: The Hitchhiker's Guide to Modern JavaScript Tooling

#91

Post by hex13 »

scribu wrote: post #18
hex13 wrote: post #11

We talk about "modern JavaScript tooling" but year after year, the list essentially stays the same. Maybe few new players have appeared (Gulp, WebPack, Babeljs) but they do exactly the same thing that the tools we had before (e.g. Grunt, Browserify, Traceur). It occurs to me that "modern JavaScript tooling" is growing only vertically (better tools to build, better tools to modularize, better tools to transpilation),…

> something that would allow me to conduct massive scale refactoring Here's an interesting tool for that: http://www.graspjs.com/ (structural search/replace)

Thanks. I'll take a look on that.

Re: The Hitchhiker's Guide to Modern JavaScript Tooling

#92

Post by oldboyFX »

iandanforth wrote: post #54

There is a fairly important point that is missed by this article. You do not need build tools to write JavaScript and depending on which tools you use there are significant drawbacks to using any them. Before you dive into the world of build tools and process management I urge you to write unminified, ES5 (aka the JavaScript that runs without transpilation today) until it hurts. Write unminified JavaScript and watch…

> Discover for yourself why these tools exist or you'll waste a ton of time learning the newest thing and in the end not have gained much at all.

Exatcly. It's important to clarify these things because so many inexperienced developers get lost in the maze of js tooling for no apparent reason.

Learning how to use these tools takes time which could be spent on learning how to program properly. And in some cases JS tooling isn't necessary at all, even in more complex projects. For example if you end up working in environments such as rails where most of these things are done automatically.

I've also noticed how people seem to look down on GUI tools such as https://incident57.com/codekit/. I think it's a great solution for beginners and people who don't need complex custom tooling.

Re: The Hitchhiker's Guide to Modern JavaScript Tooling

#93

Post by afarrell »

joesmo wrote: post #48

"The biggest weakness of such small tools approach is that it is hard to learn what to use and how to configure it." No. By far the biggest weakness of such a small tools approach is a Balkanization of development tools that generally refuse to work with one another and often don't work very well by themselves. One library I really wanted to try was using Browserify but I wanted to use brunch/bower because my workflo…

This was definitely my experience when I tried to move from python/django to javascript and gulp/browserify/foundation/nunjucks/backbone And it almost led to me getting fired. I almost certainly made rookie mistakes in trying to set up my development environment, but I think the lesson learned here is that when I try that again, I'm going to either:

1) Work with each tool individually first and really get to know it.

2) Have someone else who is experienced in this assemble the toolchain with the promise that I can come to them to debug toolchain problems.

Re: The Hitchhiker's Guide to Modern JavaScript Tooling

#94

Post by pekk »

oldboyFX wrote: post #92
iandanforth wrote: post #54

There is a fairly important point that is missed by this article. You do not need build tools to write JavaScript and depending on which tools you use there are significant drawbacks to using any them. Before you dive into the world of build tools and process management I urge you to write unminified, ES5 (aka the JavaScript that runs without transpilation today) until it hurts. Write unminified JavaScript and watch…

> Discover for yourself why these tools exist or you'll waste a ton of time learning the newest thing and in the end not have gained much at all. Exatcly. It's important to clarify these things because so many inexperienced developers get lost in the maze of js tooling for no apparent reason. Learning how to use these tools takes time which could be spent on learning how to program properly. And in some cases JS tool…

People get lost not for "no apparent reason" but because the maze of JS tooling is incredibly confusing, full of people telling you "do this, use that!" (without accounting for the other 40 things you want to use together with that) and full of stuff that is underdocumented and misdocumented and outright broken and changes every 6 months. Even if you learn "how to program properly" it doesn't in any way mean that you will be conversant with this confusing world.

Rather than blaming the user we should probably recognize there are quality problems that are the root cause of user confusion.

Re: The Hitchhiker's Guide to Modern JavaScript Tooling

#95

Post by pekk »

the8472 wrote: post #27
hex13 wrote: post #11

We talk about "modern JavaScript tooling" but year after year, the list essentially stays the same. Maybe few new players have appeared (Gulp, WebPack, Babeljs) but they do exactly the same thing that the tools we had before (e.g. Grunt, Browserify, Traceur). It occurs to me that "modern JavaScript tooling" is growing only vertically (better tools to build, better tools to modularize, better tools to transpilation),…

> * better editors for HTML/CSS, maybe even some decent WYSIWYG Editors? How about an IDE. In the java environment I can manage an application container, profiler, debugger, compiler, packager, test suite all from one application. Also included: near-omniscient auto-complete, hot-code replace, incremental building, dependency fetching, visual version control, automatic refactoring, deployment and many other convenien…

An IDE is not a fundamentally different thing from an editor, and certainly not a superior one.

Re: The Hitchhiker's Guide to Modern JavaScript Tooling

#96

Post by Zombieball »

hex13 wrote: post #76
joesmo wrote: post #49

Earlier quoted context omitted.

WebStorm ( https://www.jetbrains.com/webstorm/ ). Or if you use other languages as well, check out any of Jetbrains' IDEs: https://www.jetbrains.com/ I haven't found a better IDE for any language yet.

I think that WebStorm is decent JavaScript IDE but if we 're talking about editing HTML/CSS/Sass, WebStorm is not any better than plethora of other text editors. IMO basic problem lies in fact that we're still trying to edit hierarchical tree structures of HTML and CSS/SCSS as a plain text instead of editing underlying tree structure. I think that good HTML/CSS editor should operate on tree and every CSS rule and eve…

I agree with edwinnathaniel, IntelliJ with its browser JavaScript debugging plugins is pretty awesome and I find it a fantastic JavaScript IDE.

I am curious what use cases you have for editing in the fashion of your demo video? I don't find myself frequently wanting to view just fonts in a css file. I either have specific rules I want to edit, or I pull up reused fonts and colours into re-used classes (or less variables) and just edit that one spot.

Why would you want to view just colours? Or just fonts? BTW, I am not trying to put down your idea, infact I think it's very interesting concept to work more closely with the tree structures.

Edit: as I think about the idea, it would be awesome if I could click on any html element in a file and it would be able to statically analyze and show all applicable css selectors. Although I frequently use angular and dynamically applied css classes.

Re: The Hitchhiker's Guide to Modern JavaScript Tooling

#97

Post by guntars »

applecore wrote: post #12

The very good thing about module bundlers versus transpilers and task runners is that changing a single file doesn't result in a complete rebuild of the project; since the bundler maintains a model of the dependencies between files, it only needs to recompile the files that matter.

The downside is that now you have a whole other ecosystem of tool wrappers that tends to lag behind the tools themselves. They also tend to be JS specific, so if you have any other assets, you'll still need a regular task runner.

Re: The Hitchhiker's Guide to Modern JavaScript Tooling

#98

Post by sillygeese »

iandanforth wrote: post #54

There is a fairly important point that is missed by this article. You do not need build tools to write JavaScript and depending on which tools you use there are significant drawbacks to using any them. Before you dive into the world of build tools and process management I urge you to write unminified, ES5 (aka the JavaScript that runs without transpilation today) until it hurts. Write unminified JavaScript and watch…

> It's really only when you find yourself with a problem that you can quantify that these tools start to make sense.

Good point. Another reason to be careful is that there are too many half-assed solutions to problems that might not even be real.

Re: The Hitchhiker's Guide to Modern JavaScript Tooling

#99

Post by starik36 »

the8472 wrote: post #27
hex13 wrote: post #11

We talk about "modern JavaScript tooling" but year after year, the list essentially stays the same. Maybe few new players have appeared (Gulp, WebPack, Babeljs) but they do exactly the same thing that the tools we had before (e.g. Grunt, Browserify, Traceur). It occurs to me that "modern JavaScript tooling" is growing only vertically (better tools to build, better tools to modularize, better tools to transpilation),…

> * better editors for HTML/CSS, maybe even some decent WYSIWYG Editors? How about an IDE. In the java environment I can manage an application container, profiler, debugger, compiler, packager, test suite all from one application. Also included: near-omniscient auto-complete, hot-code replace, incremental building, dependency fetching, visual version control, automatic refactoring, deployment and many other convenien…

Give Visual Studio a try (particularly v2015). It's pretty good at auto-complete at the very least. And you could still file tickets from it as well.

Re: The Hitchhiker's Guide to Modern JavaScript Tooling

#100

Post by edwinjm »

zaphar wrote: post #71
hyperhopper wrote: post #58

Earlier quoted context omitted.

Make doesn't work on windows. Its not cross platform, while Node, and all technologies built on top of it, are.

What? http://gnuwin32.sourceforge.net/packages/make.htm

It's still not cross platform. Changes made to the Makefile under one OS might break easily under the other OS's.
Post reply on HN