[hex13]

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), but not horizontally. If we see some "brave new tool" on the scene, this tool will do exactly what previous tools did, only better.

I would like to have some decent tools for:

* analysing of project structure (e.g. dependencies between modules, graphs, trees etc.)

* code visualising (not toy! Gource is beautiful, but pretty useless. JSCity... I also don't see much use of it. I would see something that would allow me to draw some useful information from code visualisation. Something that would allow to understand better. But I see only beautiful animations and abstract 3D scenes)

* maintaining code (something that would allow me to conduct massive scale refactoring, or automatically convert code from one framework to another etc.)

* better editors for HTML/CSS, maybe even some decent WYSIWYG

Okay. Plain build systems and transpilers also are super useful. I think that Gulp, Babel.js, Browserify etc. are greeeat. But I think we need more. Something different. There is still room for innovation. Projects grow bigger and I think that we need something that helps us

* to understand easily new codebase

* to navigate codebase, conduct semantic search etc.

* to maintaining, refactoring etc.

I feel that some important tools are missing, not created yet.

[the8472]

> * 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 conveniences I'm taking for granted. Hell, I could even file tickets from my IDE if I wanted to.

[joesmo]

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.

[hex13]

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 every property should be object rather than plain text. That would allow to more natural editing and faster code modification/refactoring (I am frontend developer but I hate writing CSS/HTML by hand. It feels like using punch cards... Better editor could allow to do things faster and more effective).

I was looking for structural (and projectional) editor for HTML/CSS and didn't find any. So I started making my own (here is prototype: https://www.youtube.com/watch?v=yRwx09bAT08 )

[Zombieball]

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.

[hex13]

> or I pull up reused fonts and colours into re-used classes (or less > variables) and just edit that one spot.

good editor could pull up reused fonts and colours automatically (detecting if they the same in various nodes).

> I either have specific rules I want to edit

Yes, I'm also making possibility of filtering by specific rules and finding by CSS selector (in HTML also)

And different filters are just a part of the editor. Actually, my first idea was creating something that would allow to make quick changes that are super easy when operating on tree, but you must do them by hand in text editors (e.g. operations like "move to parent", "wrap this HTML element in new `div` element etc.).

I also want editor to be operable without keyboard/mouse switching. And because when I make websites I often use mouse to test in browser all functions, I want good mouse support and be able to change e.g. top from 0px to 10px using only mouse. This is possible in e.g. DevTools, why not to put this feature in editor?

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

Yes. It would be nice, although I didn't solve this from technical perspective yet.

But for now I think about something like in Brackets - you edit HTML and could edit styles in place without switching to the other file.

[Zombieball]

These are some great ideas. There are little features in DevTools that I wish my IDE had (or I am not aware of the features if they do).

Be sure to post anything awesome you create to HN!

[edwinnathaniel]

Decent JS IDE?

It's the best one I've tried out there. Literally. No other text-editor-with-plugins (VIM, Emacs, Sublime, Atom) or IDEs come anywhere close.

[deckar01]

Webstorm on OSX actually became more of a burden to use as my projects grew large. Excessive memory usage and crashing forced me to dump it in favor of Sublime Text. It's version history saved my butt a few times, but it was nothing that better Git habits couldn't solve.

[kriro]

WebStorm is pretty good already imo.

[ralfn]

Some of those features are only possible because Java is statically typed. They couldnt exist in the same way for "pure" JavaScript.

[recursive]

But they can exist in a statically typed extension to javascript. See typescript in Visual Studio.

[joshuapants]

I've been playing with Typescript in both Visual Studio and Visual Studio Code and Intellisense is great.

[MrBuddyCasino]

Facebook is doing something that enables better IDE support for JS, so static typing isn't absolutely required, it just makes it a lot easier. I forgot the projects name though, the IDE part was also not open sourced back then.

[feedjoelpie]

Their optional typing for JS is called Flow, and they've open sourced an IDE of sorts (a suite of Atom plugins) called Nuclide (http://nuclide.io/).

[MrBuddyCasino]

That was the one, thanks.

[rejschaap]

I have never seen anyone successfully bolt type-checking onto an existing language. It is always painful to use. It usually requires ugly added syntax and you need a special compiler if the language isn't flexible enough.

Why not just use a different language altogether? One that was designed with static type checking from the ground up?

Maybe Facebook likes the pain, they also pushed PHP further than anyone else was willing to. Burning insane amounts of resources with a somewhat disappointing result.

[starik36]

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.

[pekk]

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

[Wintamute]

I think we'll see the emergence of some of these next-gen tools once ES6+ has started to bed in. ES6 modules are much more receptive to static analysis than ES5 code.

[hex13]

Maybe... but maybe it will be like that: https://xkcd.com/927/

[aaronem]

Esprima [1] is a full-featured and quite extensible ES5 parser, which has been used as the basis for a lot of the sort of analysis tools you're thinking about here. You might want to take a look at it, and at the software that's been written around it. In particular, there are several static analysis tools you might find of interest; I don't have a handy list, but searching "esprima static analysis" should find you plenty of candidates for further investigation. Refactoring tools shouldn't be hard to write, too, given an AST. (But I'd tend to suspect that automatic conversion from one framework to another is probably a pipe dream, at least for any nontrivial code base. Frameworks tend to come with too many mutually incompatible assumptions for that to be possible without an outright rewrite. Hell, that's even true of Angular 1.x and Angular 2!)

I'd be curious to know what you mean by "better", in your fourth bullet. I can think of a few things, but I doubt they're the same things you've thought of.

(And, while I have extensive experience with WYSIWYG HTML/CSS editors, that experience lies far in my professional past, because I found they were always too inaccurate to be worth the effort. Besides, it's not like there's anything particularly difficult about just viewing your changes in an actual browser; with tools like LiveReload, you needn't even go to the modicum of effort required to hit F5.)

What kind of codebase visualization would you consider "useful"? I think that's really the hard question to answer there; implementing a visualization is probably pretty easy, compared to coming up with a visualization from which you can easily derive information that's hard or impossible to obtain any other way. (I surmise this to be a difficult question based on the fact that no such visualization exists, or at least if it does it's not well known. Otherwise, it'd probably be part of the standard toolkit by now.)

[1] http://esprima.org

[hex13]

Yes, I know about Esprima. But I think it would be perfect library to create some more high level tool. Pure Esprima is pretty low-level (and JavaScript ASTs are pretty complex to traverse).

Angular 1.* for me was just an experiment full of accidental complexity and I am glad that Angular 2 will be more simpler.

If we talk about HTML/CSS I think that we need two different kind of tools (possibly integrated):

- structural editor of HTML/CSS that would be operate on tree nodes rather than text (my previous answer: https://news.ycombinator.com/item?id=9952022 ). That would allow editor to be smarter.

- WYSIWYG in browser (realised for example via plugin extension or browser itself) as a method for tweaking end results. I think about something like that: https://twitter.com/malyw/status/615974892928954368

[scribu]

> something that would allow me to conduct massive scale refactoring

Here's an interesting tool for that: http://www.graspjs.com/ (structural search/replace)

[aaronem]

Oh hey, I didn't know about the acorn parser before now. Thanks!

[hex13]

Thanks. I'll take a look on that.

[khalilravanna]

Specifically for "analyzing of project structure" there does exist [MaDGe (Module Dependency Graph)](https://github.com/pahen/madge). You can generate some pretty nifty dependency graphs for your javascript codebase. I use it everyday when working on my game as I have a step in my gulp watch task that checks for any circular dependencies I may have introduced every time I hit save. It was a lifesaver when I made the switch over to browserify for my large game-codebase and found out I had a nightmarish dependency graph with a huge amount of cycles in it.

[hex13]

Yes, I heard about Madge, but isn't it for CommonJS and AMD only?

[OmarIsmail]

You should definitely be looking at TypeScript.

Flow is also great.