61–70 of 120 posts
Earlier quoted context omitted.
Some of those features are only possible because Java is statically typed. They couldnt exist in the same way for "pure" JavaScript.
But they can exist in a statically typed extension to javascript. See typescript in Visual Studio.
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),…
Flow is also great.
Earlier quoted context omitted.
Of course you can write code using cat but there is no good reason to do so. That would be like being a carpenter who refuses to use powertools and instead relies on manually operated ones. If you don't understand how to use the tools of the trade that will greatly improve your productivity, then you simply are not a professional.
You don't know that there's no good reason to do what I do. I use many different tools. Try ed sometime, it might improve your productivity. Professional? I deliver and get paid.
>You don't know that there's no good reason to do what I do.
Exactly. Show us.
"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…
Perhaps your research didn't lead you to an answer, however I feel like the bower/browserify isn't that big a bridge to cross. A tool like literalify[1] will allow you to 'require' globals. If you wish to require bower components, browserify-ing them isn't going to work quite well simply because normal javascript adds globals while commonjs has you explicitly get what you desire. As for CSS, there are ways to [2] inj…
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…
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…
Standalone JS was meant to add little bits of interactivity to documents. If what you're building is interactive documents, build tools are generally overkill. If you're building applications, the tools exist largely b/c JS-in-the-browser was not designed to build applications.
Earlier quoted context omitted.
> * 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…
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.