hex13

Yeah. You're right that even classes allow for great amount of dynamics. I've seen classes with decorator annotation and decorator can change classes as much as it wants. I've also seen patterns like:

class Foo {... }

// then, after class definition

Foo.A = X;

Foo.B = Y;

etc.

So... it seems that every try to make JS more static is doomed to fail... Because people will still use it in dynamic way...

Not sure how to solve this problem. Maybe we really need tooling that would run code in sandbox instead of analysing it via AST (but how to sandbox e.g. NodeJS code that interacts with file system or MongoDB? Mocking everything? Or make complete dev environments/virtual machines with NodeJS code running in it?)

(Maybe I overengineer solution ideas in my head, but I think proper tooling support is important for modern web development. It hurts me when I have to learn new large JS codebase and IDE is not helping)

> That's why a lot of React people are using flow, and a lot of Angular people are using TypeScript.

I don't like the idea of defining types for everything but maybe it's the solution (I'm not sure because I have too little experience with TypeScript to judge).

There was not such thing like ES3 module syntax. This is just programming pattern many people used: https://addyosmani.com/resources/essentialjsdesignpatterns/b...

It was a great idea back then, but that was never syntax. This and similar patterns rely on the fact JavaScript is very dynamic and flexible language and enables creating closures and creating objects dynamically.

These are very powerful features of language, but they're dynamic, which is unfortunate because to know what exactly is happening in this code you have to run it. for IDEs/editors it's hard to look at your code and guess "well, it's module pattern, I see! You mean this and that". Tooling operates usually on static analysis of syntax. They use JS parsers to parse code to AST(Abstract Syntax Tree).

And here's the thing: ES6 classes are visible in AST, there is something called ClassDeclaration. This means that every programmer can install some ES6 parser from NPM and analyse ES6 classes. This means that there will be better linting, better autocompletion etc.

On the other hand - JavaScript parsers don't understand module pattern or other homegrown idioms. It's harder to analyse them statically. Especially if they rely on dynamic aspects on language. ES6 parser doesn't run your code. That's why ES6 classes, because they're static, are better for parsers, and consequently, enable better tooling, IDE support, autocomplete etc.

Situation maybe were a little bit different if we had tooling for some sort of dynamic analysis (if tools were running code in sandbox and gathered data in runtime, not from syntax etc.).

But because currently most of tooling is syntax based I think ES6 classes (and e.g. ES6 modules) are just better for analysis.

Well... to contradict what I said early I must say that actually it's often possible to analyse such things like module pattern, createClass etc. But:

1. not always with 100% certainty of the result

2. there are too many idioms. If every framework, every team and every programmer has own way of writing JS, own module syntax, own class syntax etc. it's very hard to support all the frameworks and provide tooling for all people...

1. Sass is not as needed as it used to be (native CSS variables, PostCSS, CSS Modules, Radium, inline styles etc.).

But of course many users prefer Sass. But Sass in its CSS syntax (SCSS) is (if I'm correct) just super set of CSS. You can always start project using vanilla CSS and when project will grow, you can add Sass.

There are two approaches to develop new projects: big design up front and YAGNI principle (you ain't gonna need it). I prefer YAGNI and I'm glad that Facebook generator is so minimal. But I don't know what they are planning to do with this project. I think this project would be a lot worse if they forced to use Sass(or Radium or any opinionated CSS solution).

2. code splitting? If I understand correctly it's Webpack feature needed mainly for production, not development. So why to add this on the very beginning of your project?

Syntactic sugar? But `createClass` is a lot worse syntactic sugar than ES6 classes.

React.createClass (and angular.directive or similar guerilla solutions) are harder to analyse statically. And without static analysis you won't have proper tooling (IDE autocompletion, "go to definition" feature, dependency graphs, linting etc.).

So. Welcome language standards or goodbye static analysis. I'm seriously happy that both React and Angular go into ES6 classes and resign from guerilla coding...

it seems like a solution to the Vjeux's challenge: http://blog.vjeux.com/2015/javascript/challenge-best-javascr...

(If we don't count sharable requirement).

It's just vanilla Javascript, not some "foreign way". Checking `"somestring".indexOf(something) != -1` is common idiom in JavaScript because function indexOf returns -1 when there is no match. Just look for the definition of indexOf method on MDN: https://developer.mozilla.org/pl/docs/Web/JavaScript/Referen...

Maybe it's weird but what else could indexOf return? It couldn't return 0, because strings in JS starts from 0 (not from 1), it couldn't return null, because JS is weak typed so in some circumstances null would be not different than 0.

I'm glad that JS is not PHP (when some functions can return number or boolean or something else "just because") ;)

link: http://atom.io/packages/atom-lupa

Interesting.

I have also seen other solutions which address this problem:

1. https://github.com/facebook/fbjs library that Facebook uses in React: you have @providesModule annotations in modules, and you can write e.g. require('myModule') even if myModule.js is somewhere deep in directory hierarchy.

2. webpack configuration (e.g. you can write own loader to be able to make: require('somethingWeird'), or probably use resolve like in this article: https://medium.com/@ericclemmons/dogfooding-your-open-source...

I mean, I don't want to underestimate your project by writing that something similar existed. Quite the opposite. I think that you made library for solving important problem (resolving dependencies in nice manageable way). I am just agnostic about which solution is the best.

Although I hope that in future one solution will prevail (maybe yours, maybe webpack based, maybe @providesModule, or maybe this kind of functionality should belong to JavaScript language itself? Maybe ES8 or ES9 will have something like this?).

Because dependency management is too important for allowing to further fragmentation :)

I mean code style doesn't matter in JavaScript world. If I was developed in Python I would follow PEP8. But this just proves the point - code style doesn't matter to me much, so I could follow some other's codestyle, just to keep standards.

Code style doesn't matter but tools like Eslint (or other linters) that can enforce some unimportant stuff, can also be very huuuuuge help for JavaScript programming. They can point most JS errors, for example.

Everybody is junior developer sometimes.

Everybody sometimes makes stupid bugs and doesn't see why. Everybody sometimes doesn't know obvious things. Everybody is beginner sometimes. I think that even when senior programmer learns new approach, new project, new language, new paradigm, new tool etc. is as confused as beginner.

I think senior/middle/junior are just hierarchy markers to:

- define your salary

- define your responsibilities in project/company

- boost your ego (senior), or keep you to stay humble (junior)

"At which point the kinds of mistakes they are making are less trivial and occasionally overlap with problems `senior developer` have."

I don't know what you mean. I think every developer in a team is often experiencing similar problems. For example architecture, code quality. You could say that only seniors must be thinking about this. But this is not true, because when there is spaghetti code in project - whole team has this problem. Even junior developer has to deal with spaghetti code (for example), even if he is not experienced enough to write clean code (or even he made this code himself xD).

Besides the biggest problems in development are often not technical ones but more people/management related ones. It doesn't really matter if developers are good or bad, if the project or team is poor managed, or if there are some communication issues.

there is a Vim plugin for Ruby on Rails: https://github.com/tpope/vim-rails

like Angular does. Nothing new.

Seeing this post in context of whole conversation will show that Linus' stance was not that bad:

https://lkml.org/lkml/2000/8/22/12 (quote from Linus' post)

`It's true that "simple and tested code means less bugs". And quite often, code sharing will imply that the code gets (a) more complex and (b) has cases that people who make changes will never be able to test.

No, I'm not saying that sharing is bad. Sharing is good. But anybody who makes a blanket statement like "sharing reduces bugs" is full of crap.

Good and clear interfaces reduce bugs. Avoiding complexity reduces bugs. Using your brain before you code something up reduces bugs.

But making a very complex driver that handles ten different variations on the same hardware? No. That does _not_ reduce bugs. It's quite often more efficient to have two people work on two drivers that are independent of each other, than to have two persons working on the same driver. Alan put it well at some point: the way to create working open source software is to minimize the amount of communication needed.`

I think he's veeeeery reasonable in this. This reminds me "Wrong Abstraction" article. https://news.ycombinator.com/item?id=11032296 Sometimes it is better to create two separate things than create some weird obscure abstraction which cover all the cases.

- team work, unless somebody learned this skill in other way

- SCRUM - it would be hard to teach oneself SCRUM without job environment

- jargon (I didn't know what "pull request" or "ticket" ment before I went to the first job)

- courage, self-assurance (because of lack positive feedback from other programmers - people who learn programming on jobs are in better situation than self learners)

- realism, cynicism (Self taught programmers are sometimes too optimistic or too pessimistic and dont have sense of reality).

Besides I think everybody who e.g. makes some side-projects, or is active in open source is in fact amateur in the sense of "a person who does something (such as a sport or hobby) for pleasure and not as a job" :)

This is the old truth - premature abstraction is a root of all evil (I know original quote was "optimization", but isn't an abstraction just some "architectural optimization"? ;)

On the other hand: I often see copy pasted code which have these same characteristics author wrote about: "Another additional parameter. Another new conditional. Loop until code becomes incomprehensible."

If somebody writes too many conditionals, parameters and creates incomprehensible loops, then he will do it always, no matter whether in abstracted code or in copy pasted code...

The problem is that most of programmers are not skilled enough to write good code.

So sometimes there is a need for refactor wrong abstractions in legacy code, sometimes there is need for cleaning tons of copy-pasted code and make good abstractions... Either way - maintaining is hard.

just saying... ;)

Uhm... Usually I'm buying games on steam for 5-15 euros. There is a lot cheap special offers...

The biggest advantage of this progress is that there is a lot experimentation with new kind of tools (for example Redux Dev Tools. This is fascinating. I mean Redux is great, but the fact that there are dedicated dev tools for this? Wow. I'm waiting for new tools (maybe every popular library from now on will have its own dev tools? Or maybe somebody will make universal dev tools for all React libraries?).

I think what's happening inside React ecosystem and this constant flux of innovations is not comparable with anything in the webdev before (maybe except Ruby community which is also pretty innovative).

JavaScript :) Although I keep forgetting some functions even from JS.

No. It's not creator-janitor thing. It's rather the situation that programmer A makes a huge technical debt, and programmer B must pay him off.

It's poor code design, poor code management.

It's more like:

- irresponsible house developer builds house very fast and very cheaply but he doesn't care about safety or design

- then building is beginning to collapse and tennants have to hire another developer to fix mistakes of previous developer.

They must pay twice! One time - for creation of the building. Second time - for fixing.

Imagine that you have to create website on your laptop.

With semi-transparent editor window and with live reloading, you are able to modify website code and see instantly how website changes underneath. Without switching apps.

Asset management (for example graphic files).

I'm frontend dev and I often work on images/designs/psd's made by designers and I find it cumbersome to manually find image each time I need and to download manually to my project folder via "Save as" browser option and then copy from Downloads folder to project's folder. I think It should be automatic. Click on image and it lands in my project's asset folder (BTW this could be hard in pure web based apps. Such app would need to be desktop based to have access to hard drive).

And it should display path image was saved, to allow me to copy and paste this path to my code.

And it should display me notifications where designers put a new version of image.

I'm also disappointed when a tool doesn't offer to make comments on graphic assets or drawing arrows.

maybe Atom?

Other thing I don't know if can agree is that program's author has complete theory about his program.

I think that is oversimplification. I think that often program authors don't know what they are doing. Quite often somebody new who comes to the project has more insights about the project than original authors. Because:

1. the author can be biased (that's why we need code reviews)

2. the author can be less experienced has less programming skills, than a new person on the board.

3. the author simply lost his fresh eye for the program etc.

It's good essay, but there are some theses which I don't know if I can agree with them.

He claims that theory cannot be expressed. "(...)the knowledge held by someone who has the theory could not, in principle, be expressed in terms of rules"

Imagine that he is right and programming theory can't be expressed in words. Imagine if this was true.

Imagine there is no GoF book, no established design patterns (design patterns imo are just programming theories expressed in terms of rules...),

Imagine there is no Knuth books (if trees couldn't be expressed in terms of rules, then it would be pointless to write books about it).

Imagine there is no conferences about e.g. AngularJS or React architecture etc.

Because theory is in programmer head and "can't be expressed"

Maybe my thinking is flawed. Maybe Naur meant by "theory" something like "inner insight". If so I would agree with him. I see this quite often. People read books about design patterns and still don't understand underlying principles behind them. They just use them without deeper thinking (and they overengineer code often).

Although Naur wrote this article in context of one program but I think that programmer is building theory not only for current project but also for whole programming field. Programming skills are often independent of technology/project/language).

I don't know what happens in Google, Facebook etc. but one thing I know - there are not mainstream companies. They are just big and successful. Mainstream companies are rather all these small and medium IT firms that make Wordpress based sites (for example).

I think many IT firms nowadays have exactly this kind of approach: programmer has to deliver code according to specifications created by designers and stakeholders. Nobody cares what programmer knows and what theory programmer is building - the most important thing is to bring hot new features and to do it quickly.

Off course one can argue that "features", "stories" or "backlog" are needed from business point of view. Okay. But how to construct theory if there is no time for thinking?

nothing changes. I read some time ago Dijkstra article from 1972(!) called "The Humble Programmer" and what he wrote describes perfectly programming in 2015 as well (maybe he had Time Machine? Who knows...).

probably because JS logo has also similar colors: https://raw.githubusercontent.com/voodootikigod/logo.js/mast...