Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Do Not Follow JavaScript Trends

pragmaticpineapple.com

Post reply on HN
Print view View original

201–210 of 275 posts

Re: Do Not Follow JavaScript Trends

#201

Post by mikewhy »

novaleaf wrote: post #141
julianeon wrote: post #69

Earlier quoted context omitted.

I’m personally becoming frustrated by the “we draw the line at React hooks” idea - which I feel like I’m seeing repeated. Like that’s the point at which learning new concepts crosses over from useful exercise to useless extravagance. So let me say something which is true, but totally against the spirit of this article: there should be 10x as many (!) tutorials about how to implement everything in React using hooks. M…

I'm just now getting back into webdev after 3 years. Can you please recommend a good tutorial/demo using Hooks? Especially if it's using Typescript! I strongly dislike the create-react-app project because it abstracts everything away.

> I strongly dislike the create-react-app project because it abstracts everything away

That's the point of it, really. CRA sets up your build (webpack) and test runner (jest). Has nothing to do with hooks. I'd strongly suggest using it, unless you're interested in learning how all that stuff works.

Re: Do Not Follow JavaScript Trends

#202

Post by mettamage »

throwaway894345 wrote: post #167
gfodor wrote: post #146

Earlier quoted context omitted.

Typescript doesn't strike me as a multi-fold improvement. Dynamic vs static typing is an age-old debate, and in general, advocates can be found arguing that moving your code in either direction results in benefits. So, regardless of your stance on it, it seems unlikely to be unambiguously beneficial. Many large programs exist written in dynamic languages that do just fine.

It seems like it's trending toward static, at least recently. I think the big driver for this is the popularization of statically typed languages that aren't C++ and Java. A lot of people had painful experiences with C++ and Java and attributed that pain to static typing. It's now more clear that static typing is a net benefit, but it must be implemented reasonably and it doesn't solve other language design issues. A…

Yea, this is why I posted it. To me it seems:

- Small codebase. Fine, use both.

- Medium codebase. Fine, use both.

- Large codebase. You're definitely going to have some typing bugs with dynamically typed languages.

- Humongous codebase. You're definitely going to have many typing bugs with dynamically typed languages.

Re: Do Not Follow JavaScript Trends

#203

Post by mettamage »

kqr wrote: post #176
mettamage wrote: post #136

Earlier quoted context omitted.

How about using Typescript? That still seems like a huge improvement, especially because you can implement it incrementally (aka for parts of code where type checking is vitally important). I'm using it now at my work and I'm surprised how much info I'm getting compared to whatever JS is throwing at me.

In my opinion, if you're going to add a compilation stage to your bundling anyway, you can get far more mileage out of other options (such as Fable) than the tiny improvement TypeScript is. The additional compilation complexity is not worth the small benefits of TypeScript, in my opinion. An even better language, though? I'm in.

Never heard of Fable, will check it out! :D

Re: Do Not Follow JavaScript Trends

#204

Post by jcbrand »

MaxBarraclough wrote: post #114
thanatropism wrote: post #35

Earlier quoted context omitted.

As an outsider, I feel like React both does too much (a virtual DOM? Aren't current web standards enough to make a flower shop website?) and too little -- there's all these terms/technologies/subframeworks that people are using like "create-react-app" and "Redux" and so on. It's neither an overarching architecture that makes normal web technology obsolete but runs on it, like Windows 95, nor a website generator like…

> a virtual DOM? Aren't current web standards enough to make a flower shop website? Of today's frameworks, all but Svelte use a virtual DOM.

Not true.

litElement (used by Polymer) uses tagged template literals and no vdom.

Re: Do Not Follow JavaScript Trends

#205

Post by tfleming »

yxhuvud wrote: post #110
Tade0 wrote: post #78

Earlier quoted context omitted.

> As someone who has used Angular 2 since beta, I can tell you, it's been a bumpy ride nonetheless. Oh yeah. I remember the "let's just apply the good parts of AngularJS here and there" in v4-6. "React was built for Facebook, which is a large company building a large-scale application." One large scale application, which is not enough to create stable conventions that are badly needed in a framework that's supposed t…

> Users don't tolerate the inherent delays caused by this approach anymore. Well, I certainly also do not tolerate the delays in contemporary React sites either. Take Reddit for example, which used to be lightning fast when it was mostly serverside, which now is painfully slow, especially on mobile.

Yep, I agree. Was just talking to my wife about Reddit. It's so slow now, especially on mobile. The page constantly crashes on my Android phone and they always recommend the app. No thanks.

Re: Do Not Follow JavaScript Trends

#206

Post by throwaway894345 »

mettamage wrote: post #202
throwaway894345 wrote: post #167

Earlier quoted context omitted.

It seems like it's trending toward static, at least recently. I think the big driver for this is the popularization of statically typed languages that aren't C++ and Java. A lot of people had painful experiences with C++ and Java and attributed that pain to static typing. It's now more clear that static typing is a net benefit, but it must be implemented reasonably and it doesn't solve other language design issues. A…

Yea, this is why I posted it. To me it seems: - Small codebase. Fine, use both. - Medium codebase. Fine, use both. - Large codebase. You're definitely going to have some typing bugs with dynamically typed languages. - Humongous codebase. You're definitely going to have many typing bugs with dynamically typed languages.

I'll say that we have a small-medium code base and we see lots and lots of dynamic typing errors in production every day. I would also say "even though we have lots of people who are experienced Python developers", but I think it's actually because we have so many developers who have only developed seriously in dynamically typed languages and don't "think in types" if you will.

Re: Do Not Follow JavaScript Trends

#207

Post by throwaway894345 »

nwienert wrote: post #170
throwaway894345 wrote: post #165

Earlier quoted context omitted.

I'm not well-versed in TypeScript, and I have plenty of frustrations in Python so it's not that I don't believe you, but I do have a few questions: * Python has async/await. It's not as pleasant as goroutines, but it exists and is presumably about as pleasant as async/await in TS, at least assuming you're using or not using the type system in both cases. * Python has tuple/list/iterable destructuring. What is the spe…

Python has some async, but it never felt as core and easy. Tbh, it’s been years since I’ve done much Python. But the last time I did it was just really clear that TS had leapt ahead. Ecosystem may be part of it. Proxies are essentially meta programming tools, tbh not fully sure Python doesn’t have similar but on looking they don’t seem as intuitive.

As previously mentioned, I'm a Python critic, but it has changed a lot since you last used it. Async (for better or worse) has gained a lot of traction as have type annotations (although the type checker is a huge pain--can't model JSON or any other recursive type, can't express a callback that takes kwargs, getting it to acknowledge type stubs on upstream libraries is a forbidden art, it's pretty slow, etc).

No doubt that TS is better, however. It has amazing engines, an MS-backed developer experience, coherent type system, not the worst package management ecosystem, etc. If I could switch us off of Python to any language, I would choose Go but I wouldn't be angry if we landed on TS.

Re: Do Not Follow JavaScript Trends

#208

Post by joshribakoff »

sdfhbdf wrote: post #132
joshribakoff wrote: post #64

I find it interesting the blog post mentioned Kent Dodds article recommending everyone rewrite fetch. I just argued adamantly against Redux docs about writing tests being switched off of Enzyme to his library because it’s “more trendy”. https://github.com/reduxjs/redux/pull/3708 Unfortunately, the community overruled me and the docs no longer show how to test Redux apps with enzyme. It only shows Kent’s “react testin…

I looked through Your comments. Seems like the compromise You suggested didn't go down well. I understand the maintainers POV - just avoid the flamewars. I liked Your soluton of weighing pros and cons of the different libraries. Maybe the next step would be to create a PR to add enzyme back as a suggested alternative and just build of off this PR?

Already did exactly that FYI

Re: Do Not Follow JavaScript Trends

#210

Post by joshribakoff »

acemarke wrote: post #128
joshribakoff wrote: post #64

I find it interesting the blog post mentioned Kent Dodds article recommending everyone rewrite fetch. I just argued adamantly against Redux docs about writing tests being switched off of Enzyme to his library because it’s “more trendy”. https://github.com/reduxjs/redux/pull/3708 Unfortunately, the community overruled me and the docs no longer show how to test Redux apps with enzyme. It only shows Kent’s “react testin…

As I said in that issue, I'm not completely against having Enzyme info in that page. However, we're not obligated to have the Redux docs show information on _every_ other tool that exists in the ecosystem, and our own recommendations may change over time. Right now, we have an entire docs page on how to use Immutable.js with Redux [0]. That page was submitted by a user who cared about Immutable.js. They took the time…

Really all I want is instructions on wrapping the component under test in the redux provider that don’t presume I’m using Kent’s library. It should show how to wrap, not how to call RTLs proprietary helper function.

I’m not arguing that you’re violating anyone’s “rights” here, I’m arguing some of these trends feel like nepotism. The fact Redux and React are seemingly abandoning official support of Enzyme, after years of recommending it, after some of its users have written 100s of thousands of tests, is my issue, and I feel like is directly related the article about "trends" OP posted about.

Post reply on HN