111–120 of 120 posts
Earlier quoted context omitted.
Can you post some examples of your Makefiles? I'm trying to work out how I can replace Rails' asset pipeline without getting a headache caused by overwhelming number of node-based tools I'd have to install. Having one tool + make sounds like something I'd gladly adopt.
Here's something I made about 6 months ago: https://github.com/williamcotton/makeify
Earlier quoted context omitted.
> Well, you do at minimum need something that understands CommonJS modules, if you want to pack isomorphic code to run in the browser, so you need Browserify or Webpack. No, you don't. These are optional. You only need these for larger applications that need packing. > And you need a module downloader that resolves and installs dependencies, so you need NPM and/or Bower. No, you don't. You can manually keep things up…
> No, you don't. You can manually keep things up to date. Sure, but there are better things I could be doing with my time.
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.
Earlier quoted context omitted.
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…
Maybe given a few more hours I'd have gotten it to work correctly, but who wants to spend hours fighting bad tools, especially when just trying to evaluate them?
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),…
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 p…
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
Earlier quoted context omitted.
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 variab…
> 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 th…
Be sure to post anything awesome you create to HN!
Earlier quoted context omitted.
> 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 th…
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!
Earlier quoted context omitted.
Unix much? My biggest hesitation about WebPack is that it does too much and duplicates so many other tools. If I'm already using Gulp to watch files and BrowserSync (love!) as my local dev server, why do I need WebPack when I'm only going to be using one of its abilities? Isn't this bloat?
Well the question is why bother with those other tools if one tool (Webpack) can do everything you need?
Earlier quoted context omitted.
I agree that it's essential and nourishing to understand the basics, but I feel that familiarity with the basics and expertise with these tools represents a minimum baseline standard for professional frontend development, especially when working in teams on medium/large web apps. Granted it's not easy to get up to speed with all of it, but many fields in programming and CS are not easy either. As browsers become incr…
Well, one thing about JavaScript is that it's a very flexible language in itself without any additions. It's similar to something like Scheme. And good Schemers can accomplish a lot of cool stuff with the proverbial Notepad. I'd rather hire someone with no clue about Gulp or npm but who understands all of JavaScript and knows how to do stuff in the simplest possible way, than someone who's mastered all of these tools…
Amen to that! I think what I'm trying to say, and I suspect that we agree, is that there's the right tool for a job. Setting up a project to use 200mb of over-complicated npm modules and tools probably signifies the work of an inexperienced craftsman. Likewise, a non-trivial project built entirely from home-grown native Javascript may well run into complexity problems too as it re-implements features for which simple, well-tested and widely-used open source modules are available. Our desire for simplicity will lead us variously towards either of these extremes, and our experience tells us how to tread. We want our projects to be "simple", but that doesn't mean they're going to be "easy". The barrier to entry for frontend development is increasing in terms of developer capability, but that doesn't mean complexity is increasing, or that well architected projects that use modern tooling aren't simple.
Earlier quoted context omitted.
Well, one thing about JavaScript is that it's a very flexible language in itself without any additions. It's similar to something like Scheme. And good Schemers can accomplish a lot of cool stuff with the proverbial Notepad. I'd rather hire someone with no clue about Gulp or npm but who understands all of JavaScript and knows how to do stuff in the simplest possible way, than someone who's mastered all of these tools…
> When I see a complex build tool replaced with three lines of bash, that makes me happy Amen to that! I think what I'm trying to say, and I suspect that we agree, is that there's the right tool for a job. Setting up a project to use 200mb of over-complicated npm modules and tools probably signifies the work of an inexperienced craftsman. Likewise, a non-trivial project built entirely from home-grown native Javascrip…