8 ms·
Things People Eventually Learn About JavaScript Projects
- ranci 8y agoThe last thing I want in a project I am working on is for the main programming language itself to be "an adventure'. Software development is hard enough, I don't need anymore "adventures" from the underlying language or tools.
- sandyarmstrong 8y agoIf you look past the first line, it's all just general software development advice and has pretty much nothing to do with JavaScript. I'm not really sure why it's on HN at all.
- collinf 8y agoI come to HN to avoid these Medium articles shilling their personal twitter account disguised an article that has already been written 25 times. Your typical Medium article: 6 reasons why you need Async in your Javascript code! (generic article with no _new_ points being made) By the way, follow me on Twitter and like my start up on Instagram! /s
- tlrobinson 8y agoThe author wasn't suggesting JavaScript being an "adventure" was a good thing. If you build web applications JavaScript is pretty much a fact of life. This article provides pretty reasonable advise on how to make it manageable.
- mLuby 8y agoA couple of those points could be boiled down to "use a strict linter with most of the rules turned on".
- tehlike 8y agoor typescript?
- wildpeaks 8y agoOr even both because Eslint has a Typescript parser too now. This is the config I use with Typescript projects, if you're looking for inspiration: https://www.npmjs.com/package/@wildpeaks/eslint-config-typescript https://www.npmjs.com/package/@wildpeaks/eslint-config-types...
- Zalastax 8y agoHow does it compare to using TSLint?
- stareatgoats 8y agoAlways interesting to hear someones distilled opinions about what constitutes best practices. There are mainly 2 things I'd personally add: (1) to keep an eye on 'Time-to-Interactive', it doesn't seem to be of concern at all to the author. Also, (2) Npm is a great resource, but I would not reuse components I might find there without some serious research, dependencies can get totally unmanageable.
- komali2 8y ago>Focus on making things simple, without a need for documentation or comments. I had a coworker that would love to make super long underscore chains without any comments. Drove me insane. I still find them here and there and break them apart into line by line commented dead simple code. When I was in a bootcamp we'd do code golfy type things, taking advantage of the newest ES features to shrink stuff way down. Was cool then, now when I see answers like that on stack overflow I'm tempted to repost them "in English."
- DogLover_ 8y agoSame old recommendations. Some things to consider imo: 1. Using x as variable name can sometimes increase readability. For generic functions that are close to mathematics it is not a sin to use such variable names. Though way to often I get pointed out to rename it to something more descriptive. Longer variable names can also leads to worse readability since a linter will now make 1-liner split into a 4-liner. 2. Tests: "With increasing complexity your codebase will become much harder to maintain and control — tests will do it for you." Good intentions here but be careful. Tests can cause people not wanting to refactor/fix because now they have to fix the structure of the tests. Refactor means more than changing the implementation of functions. 3. "Commit daily,... . Give meaningful commit messages." I am starting to see a trend where PRs get squashed into one commit. Thus making such advice not very useful.
- dagoat 8y ago> Thus making such advice not very useful. Even with a squash, I think there is value in committing frequently and with good commit messages.
- rzzzt 8y agoMeaningful commit messages on the feature branch make it easy to compile a list of changes for the PR; in the case of GitHub, the squashed commit's message for the PR lists the individual commits that make it up in the larger text box, which can be nicely formatted into bullet points.
- jetrink 8y agoThe Clojure world has a set single-letter naming conventions that, since they are widely accepted, greatly improve readability. If you see an argument named `f`, you can be sure it is a function. `m` is a map, while `k` and `v` are used for keys and values, respectively. `x` and `y` are numbers and `n` is always an integer.
- FlipperBucket 8y agoI prefer a convention of semantically relevant variable names prefixed/suffixed by a letter indicating type.
- hashrate 8y ago> Angular / VueJS / Ember: when you need a webapp done quick and reliable, > in exchange allowing a big black-box instead of an architecture. Here we have the typical "coder" mindset, It's very clear reading these line that the developer has never experienced with those frameworks as both Angular and Vue has very strong and well designed architecture which are obviously open source. Unfortunately it's very rare these days to find developers that can argue passed beyond "Google Trends Charts" and "Github Stars" about what makes a good or bad framework and why X is better than Y or why X architecture is more efficient than Y. > React: when you need total control over the architecture Could the author be more specific here ? I don't remember "Ruby on Rails" to give much freedom in terms of architecture yet it empowers thousands of large traffic web apps without any problems. It sounded as very common beginner beliefs which is "It's not possible to do this with [Angular/Vue]". Hence the majority of the article isn't really specific to JS.
- britch 8y agoI took the more control to mean React gives you more choice over what libraries you want to include in your architecture, whereas Angular/VueJs. are more opinionated. HTTP call libraries are a good example. Angular comes with HttpClient in the box, and while it might be possible to use something else, Angular is really going to prefer if you makre your HTTP calls using HttpClient. As I understand it, React does not have a parallel. React shrugs its shoulders and says "use what you want," whether it's just using fetch or some other JS library. Total control is maybe an extreme way to put it, but React certainly more "fill in the blank" than the other frameworks.
- TheCoelacanth 8y agoIt's supposed to be a bad thing that React doesn't add yet another way of making HTTP calls? There is already a standard way of doing that (fetch). Why should a web framework add another one?
- deleted 8y ago[deleted]
- ng12 8y ago> React: when you need total control over the architecture and build, but only for webapps built with components. React-ecosystem development takes time and requires a lot of planning beforehand. React pays back plenty, but only if you know what you are doing. Complete nonsense. React is not any more complicated than Vue and I think it's significantly easier for newbies to grok than Angular (with some non-trivial anecdotal evidence to back this up). I do not understand where this perception comes from. My best guess is that React scales well to complicated applications which makes people think that's what it's geared for. Maybe I'm lucky that I learned React in the "early days" before this perception was common.
- swsieber 8y agoI think this sentiment comes from the fact that React is not a complete solution, and for big projects, you will have to make several impactful decision about architecture as it relates to using React. Angular and Vue don't encounter this as much because they are more broad, and more opinionated.
- linkmotif 8y agoReact is not a complete solution? What are you referring to? It’s a complete solution for describing what you want on the screen and not worrying about how that happens. It comes with build tools. What else do you want?
- britch 8y agoReact is frequently mentioned in the same breath as Angular/Vue/etc. Angular, for example, has most of what you'd want to build a complex web app built. Compared to that, React is not "complete" because if you wanted to build a complex web app you'd need to start using outside libraries or writing a great deal of code yourself. I agree this does not mean React is "incomplete." It does what it sets out to do very well. But the discussion is often framed as React vs Vue vs Angular, fair or not.
- 8y ago
- a13n 8y agoAren't these great recommendations for any programming language? Simplify your code, use version control, write tests, use helpful names... What does this have to do with JavaScript?
- Sharlin 8y agoJS is probably the language most junior devs are familiar with, these days. And, partially due to that, also probably the one with the worst and hackiest real-world practices.
- prithvi24 8y agoAlthough unit tests are important, I think it is pretty important to emphasize the importance of a static type checker like flow. It is expensive to invest in test coverage, and static type checking is a good proxy to help capture many regressions. Sure its not perfect, but we should encourage it as a "best practice".
- Sharlin 8y agoPerhaps this is aimed at very junior developers, but it pains me that "organize your code into multiple files by functionality" is something that must be separately mentioned.
- aylmao 8y agoGood article. This applies to all projects-- JavaScript or not.
- the_cat_kittles 8y agothings you will learn about javascript: - hosting is cool and can help you arrange code more intuitively - closures are useful - knowing the actual language itself and not just frameworks is very good - use a linter and style checker because the language is too flexible if working with a team - chrome debugging console mastery is a boon - code preprocessors like grunt and babel etc are annoying but can be useful - reading the actual language specs is a very good way to be knowledgeable (i never did, but my coworker who did was super helpful because of this) - using imports and modular patterns is probably a good idea (they got this one, kudos!) - its very easy to bloat up a project with npm, making stuff yourself is often totally ok, and often very good - most people do not know the actual language, and confuse frameworks and patterns with the language - one of javascripts greatest strengths is its ubiquity, you can run programs on any almost any web connected device almost instantly. you can use this to great effect i write those because i think this article is mostly making points that are generic and dont apply specifically to js. im sure i forgot alot, just freestyled!
- jasim 8y agoIf you are lucky, the thing you will eventually learn about JavaScript is to use either TypeScript, Flow, Elm, Reason, or PureScript. If you are unlucky, you might get attached too much to design decisions made by Brendan Eich because he didn't have enough time to design the language, and nobody knew how big the web was going to get. Also because statically typed functional programming was so far marred by lack of good learning material and bad tooling. That has changed. Now is the time to get back to start using scripting languages for scripting, and more sophisticated languages for building more sophisticated things, which rich front-end applications definitely are. Many writings about programming that get popular are predicated on dynamic languages, and thus about coping with them rather than stretching the limits of what you can make the computer do. "Name your variables", "write comments", "use framework X over Y". These things stop being a worry once you let the compiler become your pair-programmer and tell it through types what you're trying to do, and it'll become your safety harness, and the types your tools of thought. Amazing stuff.
- luord 8y agoI don't understand your point, or maybe it's just the tone. You seem to be treating "static typing is better" as a fact of life that people working with dynamic languages eventually learn if they're "lucky". This is completely at odds with, well, reality: static vs dynamic has been going on for over sixty years, essentially since the first days of computer science. You fall in one camp, all the power to you, but it isn't better and doesn't make you "more lucky". They have their pros and cons and many a paper and book has been written comparing them.
- jasim 8y agoI should've been better with the tone. My view still holds. I know programmers who've written large swaths of Haskell and OCaml, who however reach for the eminently dynamic Racket for its metaprogramming. They know the relative strengths of each paradigm better than most of us and have fine judgement. However junior programmers (<10 years) who haven't spent the effort required to learn other paradigms and are religious about whatever language they chose to learn as an accident of history are missing out tremendously. Most of the static vs dynamic type research has always been about C++ based static types (which combines Simula-67's object system with Pascal's types - more history here: https://twitter.com/jasim_ab/status/991948718508130304 https://twitter.com/jasim_ab/status/991948718508130304) contrasted first against LISP and later with languages like Python, Ruby, and Javascript. Statically typed FP is totally different, and there are papers on either side of the bias to point to. I will recommend the Elm Language as a good starting point for anyone interested in seeing what Typed FP truly can be.
- mal10c 8y agoI think those points could be applied to most languages. My personal favorite is "Make things embarrassingly obvious." I've been programming for nearly 20 years and I can say without a doubt that's one of the most useful things to keep in mind on large scale projects. Keeping things obvious allows me get through bugs, and get the product to the customer faster.
- _bxg1 8y agoMost of this is pretty nonspecific to JS, just basic general good-practices.