Hacker News Reader

Comment by antihero | Hacker News Reader

Man, I hope I don't have to work on their code ever (edit: to clarify, I am not knocking their actual code!)

Being so against using any sort of transpilation you avoid even TypeScript and JSX? Even though Parcel gives you these things completely for free, out of the box?

I do not think this approach would scale to a team in any good way.

Also with regards to using something like unpkg URLs in built code, whilst I a not completely against using urls for dependencies (ala deno), isn't there the huge risk that without pulling dependencies in at build time, those URLs will break or become overloaded or compromised?

View on HN

As I said, I freelance. So don't worry, because I'm not planning to hire you ( ͡° ͜ʖ ͡°)

> Also with regards to using something like unpkg URLs in built code, whilst I a not completely against using urls for dependencies (ala deno), isn't there the huge risk that without pulling dependencies in at build time, those URLs will break or become overloaded or compromised?

In my post, I said I use unpkg for prototypes, so I don't think it's a problem. But in any case, unpkg let's you pin a version:

unpkg.com/:package@:version/:file

No worries buddy, and I think that it's important that you enjoy using something that works for you. I just thought it prudent to point out the limited scope of certain approaches as there's a lot of people trying to push this kind of simplicty into situations where it is less appropriate (in my opinion).

I'd rather see more of a chase for simplicity these days. It is the hallmark of good project. However today the opposite is popular.

Indeed. If 40-something me could go back in time and tell 20-something me what I’d learned in my career so far, one of the first lessons would be that simplicity scales and endures like almost nothing else and is probably the most underrated virtue in software development. (Composability would be #2.)

That is not to say that complexity is never necessary. Sometimes we are trying to solve inherently complex problems. But there is a disturbing amount of accidental complexity in modern web development. To make things worse, because web development is such a huge part of the software industry now and how so many people have come into that industry, a whole generation of developers is growing up believing that the accidental complexity is necessary or even desirable.

I've been trying to move away from things like create-react-app and towards things like Parcel, but pretty most statically typed stack has some sort "compile time" typechecking that would be needless to have in the browser. Ergo, expecting the browser to do everything we want to provide a development environment is going to be a tough call. It would be lush if Firefox and Chrome supported TypeScript natively, but it would always lag behind I think.

I currently am working on a typescript + react + redux application. The number of times I have had a developer on my team tell me that a change will be hard is disturbingly high. In vanilla javascript it would be a simple sixty minute change.

I actually really like typescript but I am unaware of being able to use it without very obnoxious things like webpack being involved.

I can't wait 'till Parcel 2 is stable, but yeah with Parcel you just include it and boom, it works.

Adapting existing projects is harder though.

With React and Redux everything is hard. These are two worst mainstream libraries out there. It so bad, even Typescript can not help too much.

It really isn't, though? I think redux introduces a LOT of complexity and much prefer something like Mobx-State-Tree, but React has been a total breeze.

For me it is still surprising how much time and effort you have to take to solve problems that was actually solved years ago. But I can understand that for beginners, or people that used vanilla JS or jQuery React is a step forward. For me, it is a big step backwards.

> I do not think this approach would scale to a team in any good way.

I mean, he literally says he's a solo/freelancer. Should be pretty clear:

> I'm sure they won't work for everyone as all our contexts differ. But working solo as a freelancer, I've found that these principles contribute to me being content about what I'm doing. Hence, I was eager to share them.

Honestly, if you're doing solo/freelance work, whoever comes along next is likely to toss out whatever you've done anyway, so you may as well optimize for whatever stack works best for you.

> Honestly, if you're doing solo/freelance work, whoever comes along next is likely to toss out whatever you've done anyway, so you may as well optimize for whatever stack works best for you.

This is a fair point

Parcel doesn’t come for free. It does help, but it brings its own problems.

If you stick an await in the code it breaks it because it transpiles it to a missing library. You have to disable Babel or import a regenerator/polyfill or whatever they need nowadays… but first, you have to figure out what’s wrong.

I didn't say Parcel comes for free - for clarification, the author said they use Parcel, and I am saying that this comes for free with Parcel.

> Even though Parcel gives you these things completely for free, out of the box?

Not only is it free OOTB, but iirc you can't turn it off[1]. So OP might be using it unknowingly. 0 config means just that, for better and worse.

[1] - https://github.com/parcel-bundler/parcel/issues/1207#issueco...

I've worked on a team that was quagmired with tooling. I would love to work with this code base.

What makes you think this approach will make it harder for other developers to work on the code?

One advantage is that there are fewer technologies another developer arriving needs to know to even get started working on the code.

Reply on news.ycombinator.com