Comment by mhink | Hacker News Reader

Comment by mhink | Hacker News Reader

Parent Full thread

Since 2016... yes, more or less.

Webpack became the de-facto standard for bundling for a few years there, but everybody hated configuring it, so it dramatically increased the "out-of-the-box" configuration. That said, the ES module standard has started to make its way into the world, so there are more than a few bundlers these days that aim to do Webpack's job better. They've also learned from years past, and most try very hard to remain "zero-config".

TypeScript has become extremely widespread, and has finally reached a reasonable level of maturity, in the sense that 1. most libraries now come with type definitions, and 2. its type system is sophisticated enough to express (and infer types for) common Javascript patterns. For non-Typescript code, Babel is still quite common, although like I mentioned, most bundlers are trying to avoid making you explicitly configure your compiler, so it's much less of a PITA to get working.

In runtime-land, I can only really speak to React. It's come quite a long way in the past couple years- the main difference is the introduction of "function components" rather than the previous "class MyComponent extends React.Component". These function components use a new effect/state management architecture (called 'hooks') that's sort of like a DSL. Personally I really like it, but it's kinda divisive. Next.JS has emerged as sort of the standard "React front-end framework", and it's quite nice- again, people took "Javascript fatigue" pretty seriously, so there's much less fussy configuration.

In semi-related tech, GraphQL has become quite popular for APIs, and there are a few libraries out there to help handle it.

Oh, and the Prettier formatter became popular, for whatever reason, which makes me want to bang my head against a wall because in spite of the name, it makes everything it touches uglier.

Anyways, I know that was kind of a wall of text, but the takeaway here is that although a bunch of new stuff happened, FE tooling is definitely trying to be more mature and avoid a Cambrian explosion of new stuff like there was back then. Hope that helps!

I actually really like Prettier. It ensures that everyone's code ends up formatted the same, and when you're working on a project that a bunch of different people touch, that makes reading the code so much easier. It may not always be beautiful, but at least it's consistent and readable.

It also means I have to spend zero time worrying about formatting. Now I often just type stuff out on one ugly line, then hit ctrl+s and everything magically formats itself, it's honestly great. Whenever I work on code without Prettier it makes me realize how much time I spend just formatting things.

I don't have a problem with the idea of a formatter (gofmt is freaking amazing), but Prettier itself makes extremely asinine and frustrating formatting decisions.

> It may not always be beautiful, but at least it's consistent and readable.

"Consistent" as in a consistent set of rules applied across the team, sure. But Prettier-formatted code ends up being extremely internally inconsistent. The best example (and the one that drives me bonkers the most) is function parameters (both traditional params and destructured-object params). Prettier forces you to go with whatever decision IT thinks is best about lining stuff up, meaning it'll force you to change:

    const myFunction = ({
      xAttr,
      yAttr,
    }) => {
      // ...
    };

into

    const myFunction = ({ xAttr, yAttr }) => {
      // ...
    };

That is, until you add another param:

    const myFunction = ({ xAttr, yAttr, anotherPropIAddedLater }) => {
      // ...
    };

And THEN it'll reformat it to a vertical list. Which is what I wanted all along! I could go on about other formatting BS it does (hooks in React are another good example) but I think I got my point across.

Again, like- I don't necessarily think formatters are a bad thing in principle. What I hate is the fact that the most commonly used formatter in JS-land is so mediocre in its output.

Your specific example makes perfect sense to me. It starts wrapping when you exceed the line length limit. It would be a bad formatter if it didn't do that.

No? Tons of formatters respect user-introduced whitespace, which is a good thing to do.

One of the main selling points of Prettier for a lot of people is that it is extremely opinionated and leaves very little formatting choices up to the user. If you respect user-introduced whitespace then the same code written by two different people can end up formatted differently, which is precisely the problem Prettier is trying to to solve.

I would argue the example posted above is still "consistent" because the rules Prettier follows for line breaks (and everything else) are consistent throughout the codebase. Things will be on one line until the line is too long or complex, and then it will break to multiple lines. The rules don't change depending on who was writing the code, what the code is, or any other factors. It may not be formatted exactly how you want, but that's kind of the whole point. It's formatted how Prettier wants, and that's the only option.

I love that this is being 100% serious and is probably close to 60% the wordcount of the parody article.

I know enough of javascript when I did it back in 2010 as to WHY people built all that. It's still basically the same feeling as watching the movie Brazil.

How will Webassembly possibly handle backwards compatibility to old browsers? Webassembly --> asm.js transpiling?

Edit: yes it will. And apparently Webassembly is actually Lisp.

Hm, I can see webassembly equalling/surpassing the JVM in technical capability. That might be a pretty good thing, because javascript on the server was never a good idea.

WebAssembly isn't a Lisp, it just happens to have an s-expr representation

After working with it for a while you get used to the ugliness from prettier, but still I really wish JetBrains would release their formatter as a prettier alternative / competitor.

Agree on all points...except Prettier, which is manna from the gods. Better to get used to it than to fight it.

It's ok except the wrapping rules. Everything turns out into vertical grotesque - and TypeScript has longer lines because of type names so it wraps often.

I use it with TypeScript, and I find the wrapped lines to be far more readable. You get used to it.

Many people do, though I understand it's a point of religion for some to Not Wrap Lines.

Had a short contract recently with a company that had a small team of two developers. My widest reaching contribution to the team, I think, was to vote with the team lead to adopt Prettier.

Their previous approach was to _never wrap import lines_. There were literally 1000-character import lines. One of the developers was totally religiously opposed to ever wrapping them. Deltas in PRs were impossible to actually parse with huge lines like that, and if two people modified the same import line, merging the two changes was a nightmare.

But with a facade of Democracy, the team lead was able to finally adopt Prettier and its wrapping to the project. This despite the fact that I'd already let it be known that I was only staying until the end of the contract (about three months) and moving on. Whatever works.

While fetch rules the browser, it’s still anybody’s game for succeeding request.js for node.

Recently I’ve been going with got.

I haven't really been following, but I just sort of would have assumed that node-fetch or equivalent would be mainlined into nodejs. I get that nodejs is not in the habit of replicating browser APIs, but it seems like that one, at least, would be on-point for nodejs.

Node-fetch?

Thanks, that does!

Reply on news.ycombinator.com