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

241–250 of 275 posts

Re: Do Not Follow JavaScript Trends

#241

Post by rowanG077 »

wegs wrote: post #236
rowanG077 wrote: post #230

Earlier quoted context omitted.

I don't really see how the first example is incompatible with static types. Most often type inference infers the most general type possible. That means you can do exactly the same things with that lambda in a statically types language as in a dynamic language. The second example with count of apples and oranges is bad. Those are unitless and a thus Just an natural should be fine for them. Numerical code can get messy…

I agree that well-designed type systems can be helpful, and in an ideal case, I'd have a mix. It's just that TypeScript is not that. The gap between the types of type systems you're describing and TypeScript is the Grand Canyon. re: type inference Inferential type systems fall into a fuzzy zone between statically and dynamically typed. For example, many JITs for dynamically typed languages do type inference, and gene…

Well yeah typescripts typing sucks but that's not my point. Type inference falls squarely in the static typing camp. It has nothing to do with dynamic typing.

Take a look at the Haskell units library. That can do the things you illustrate.

Re: Do Not Follow JavaScript Trends

#242

Post by mercer »

ng12 wrote: post #194
013a wrote: post #142

Earlier quoted context omitted.

Yeah; I think your timeline is off. I don't remember React being the very clear choice until probably 2017. It was still up in the air in 2016, and certainly moreso in 2015. > by 2015 React "won" the framework battle. Things have calmed down now. Its better, and has been for a couple years (not 5+ years). But, this isn't a battle. Its not a war. Just because things are calm now, doesn't mean they won't go crazy again…

Either way the article is way off: > Let us quickly travel back in time to 2016 ... If you are using a JavaScript framework or want to use a framework, Angular.js is probably something you would choose Angula.JS was in the "failed experiment" category by 2016. The announcement that Angular2 was a rewrite (in 2014) was proof of that. So in 2016 Angular was still really new and React had eaten AngularJS's market share.

I completely disagree, at least when it comes to my surroundings.

In 2016, the vast majority of recruitment offers I received were Angular, or jQuery/javascript. And while HN (thankfully) was all about React and whatnot, this situation continued for a good few years. Angular was the safe choice which I guess the PM's wouldn't get fired for. I remember many, many conversations with various recruiters where I told them I refused to do Angular projects, but I'd love to work on a React or even 'vanilla' JS project.

I'd say that after React became 'standard' on HN (around the time Vue popped up I suppose?), it took at least 2 years before I started getting emails and calls from people looking for React work.

Currently hoping this will happen with Elixir but not getting my hopes up :). Still, not having this sword of damocles hanging over my head that 'maybe I should learn Angular' is real nice.

Re: Do Not Follow JavaScript Trends

#243

Post by mercer »

phponpcp wrote: post #153
013a wrote: post #142

Earlier quoted context omitted.

Yeah; I think your timeline is off. I don't remember React being the very clear choice until probably 2017. It was still up in the air in 2016, and certainly moreso in 2015. > by 2015 React "won" the framework battle. Things have calmed down now. Its better, and has been for a couple years (not 5+ years). But, this isn't a battle. Its not a war. Just because things are calm now, doesn't mean they won't go crazy again…

"I don't remember React being the very clear choice until probably 2017." Maybe you werent paying attention then.

It wasn't in many places even until 2018 at least. HN isn't the real world.

Re: Do Not Follow JavaScript Trends

#244

Post by mercer »

ehnto wrote: post #147
andrewl-hn wrote: post #92

I vividly remember 2016. I was doing backend programming at the time, but no one I knew were using Angular.js at that time for new codebases. React emerged in 2013, by 2014 the hype was at full swing, and by 2015 React "won" the framework battle. It's been 5+ years since then, and React JavaScript world was remarkably stable. Fashion changes were largely superficial: React.createClass vs ES classes, Heavy use of Deco…

You make it sound like we're all using React and that's all there is to it. That's not quite true, and it's just one of the choices you have to make. So you've decided on React, but what about state management, transpilation, do you use GraphQL? What am I doing for styles, should I write them in Javascript too now? Oh no! Webpack isn't for me! Can I use modules yet? Ah bugger, we need SSR, suppose I should have manag…

Just use Next! I mean Nuxt! I mean really just give up and go for Phoenix LiveView or TurboLinks or Blazor...

Re: Do Not Follow JavaScript Trends

#245

Post by mercer »

strbean wrote: post #198
tarsinge wrote: post #115

Earlier quoted context omitted.

You are overly optimistic with the timeline. No, React had not "won" by 2015, not even by 2016[0]. Also the burn of more than half a decade is very real, both on developers and in codebases. [0] http://2016.stateofjs.com/2016/frontend/ . From that link: > What's more, there's just so many options: Do you use React or Angular 2? Do you really need Webpack? And what's this month's recommended way of dealing with CSS? >…

From that survey, is you look at positive (would like to learn + would use again) vs. negative responses (not interested + would not use again), it looks like React is crushing everything outright. 85% positive / 15% negative. Amongst the other frameworks, the only one without at least 50% negative response is Vue at 43% positive / 35% negative, with a heart "never heard of it" segment as well.

Who cares what developers 'like to learn/use' when in practice they often don't get to, or get lucky and their preferred approach/tech is considered 'safe' a few years later?

Re: Do Not Follow JavaScript Trends

#246

Post by mercer »

gfodor wrote: post #174
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…

Hard to say. It seems as cyclic as anything else. Hard to tease apart real benefit from the usual fad/hype cycles. Ruby, Python, Erlang/Elixir, Lisp/Clojure, etc, all doing just fine without it. (Some, with some lightweight annotative-oriented typing for a subset of projects.) The best counterargument to static typing I can articulate is that in general, the only way to be sure software works is to run it. And so, ul…

I'm not disagreeing per se, but at least in the Elixir community I get the impression that using Dialyzer (the wonderfully cryptic TS-ish gradual typing solution) and typespecs is increasingly advised and there's a thirst for a better solution. But static typing comes up a lot.

We're doing fine without, but it's definitely a sore point and I'm one of those developers who has become more and more fond of static typing.

Re: Do Not Follow JavaScript Trends

#247

Post by throwaway894345 »

gfodor wrote: post #174
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…

Hard to say. It seems as cyclic as anything else. Hard to tease apart real benefit from the usual fad/hype cycles. Ruby, Python, Erlang/Elixir, Lisp/Clojure, etc, all doing just fine without it. (Some, with some lightweight annotative-oriented typing for a subset of projects.) The best counterargument to static typing I can articulate is that in general, the only way to be sure software works is to run it. And so, ul…

Python is trending toward types via support for type annotations. My extensive experience with Python and Go leads me to the conclusion that it’s very difficult to write even moderately complex and maintainable Python code at scale. This doesn’t mean that no one can make money with Python—far from it—only that they would make even more money via Go (iterate faster and spend less time fixing bugs). Of course this can’t necessarily be extended to other languages. C++ and Rust would not be as productive up front than Python and C++ would probably not save you any time fixing bugs. A lisp might be faster to develop in than Go and Python without incurring too many type errors. There are too many variables to make sweeping statements, but all else equal, in my experience, static typing is better than dynamic typing. But again, there are many other variables that can cause a dynamically typed language to outperform a statically typed language for iteration velocity or bug reduction.

Re: Do Not Follow JavaScript Trends

#248

Post by [deleted] »

wzy wrote: post #181
ehnto wrote: post #147

Earlier quoted context omitted.

You make it sound like we're all using React and that's all there is to it. That's not quite true, and it's just one of the choices you have to make. So you've decided on React, but what about state management, transpilation, do you use GraphQL? What am I doing for styles, should I write them in Javascript too now? Oh no! Webpack isn't for me! Can I use modules yet? Ah bugger, we need SSR, suppose I should have manag…

I even got fatigued reading your list of choices and you even missed critical choice such as flavor of SSR.

[deleted]

Re: Do Not Follow JavaScript Trends

#249

Post by throwaway894345 »

blackrock wrote: post #234
throwaway894345 wrote: post #206

Earlier quoted context omitted.

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.

Can’t you write the Python functions to force check the input parameter for its type? And error out if not. This should enable you to catch most errors immediately during development.

No, this doesn’t help at all. You only hit these errors if you run those paths in your tests, but those paths would already error downstream. Those paths that weren’t tested may still contain errors that go to production, and again you just hit your new type error instead of the downstream type error.

What you need is something that can help you test more paths, and static type checking checks all paths. Further, they can check all paths without writing any tests (you should still have tests, but you need fewer with a static type system to keep your bug rate the same). Moreover, static type checkers catch errors almost immediately, so you get feedback about your errors sooner rather and more frequently, so you spend less time investing in code that will have to be rewritten. Lastly, they put rails on the code—it’s harder to write bad code including gratuitously magical or abstract code, so your coworkers aren’t writing as much bas code that you have to interface with. If you find static type systems to be frustrating, you’re probably the problematic coworker. :)

Re: Do Not Follow JavaScript Trends

#250

Post by throwaway894345 »

mixmastamyk wrote: post #239
blackrock wrote: post #234

Earlier quoted context omitted.

Can’t you write the Python functions to force check the input parameter for its type? And error out if not. This should enable you to catch most errors immediately during development.

Yes, but easier to just write tests.

And easier still just to use static types.
Post reply on HN