5 ms·
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
by hex13 11y ago
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.
- scribu 11y ago> something that would allow me to conduct massive scale refactoring Here's an interesting tool for that: http://www.graspjs.com/ http://www.graspjs.com/ (structural search/replace)
- aaronem 11y agoEsprima [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 http://esprima.org
- hex13 11y agoYes, 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 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 https://twitter.com/malyw/status/615974892928954368
- the8472 11y ago> * 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.
- kriro 11y agoWebStorm is pretty good already imo.
- ralfn 11y agoSome of those features are only possible because Java is statically typed. They couldnt exist in the same way for "pure" JavaScript.
- recursive 11y agoBut they can exist in a statically typed extension to javascript. See typescript in Visual Studio.
- joshuapants 11y agoI've been playing with Typescript in both Visual Studio and Visual Studio Code and Intellisense is great.
- MrBuddyCasino 11y agoFacebook 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 11y agoTheir 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/ http://nuclide.io/).
- Wintamute 11y agoI 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 11y agoMaybe... but maybe it will be like that: https://xkcd.com/927/ https://xkcd.com/927/
- OmarIsmail 11y agoYou should definitely be looking at TypeScript. Flow is also great.
- khalilravanna 11y agoSpecifically for "analyzing of project structure" there does exist [MaDGe (Module Dependency Graph)](https://github.com/pahen/madge 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 11y agoYes, I heard about Madge, but isn't it for CommonJS and AMD only?