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

231–240 of 275 posts

Re: Do Not Follow JavaScript Trends

#231

Post by runawaybottle »

christophilus wrote: post #62
runawaybottle wrote: post #17

Earlier quoted context omitted.

But do we get it? If we get it, why is frontend churn so prevalent? I don’t think we get it.

Is front end churn really so prevalent? I hear this opinion all the time, but React is 7 years old. I've been using it for around 5 years, I think. Redux is 5 years old. How old does the most popular web framework need to be before we consider it to be low churn? [Edit: Also, anecdote: before JS, I was mostly a C# developer, and the churn there was at least as bad, maybe worse in my personal experience. Over 15 years…

I’m not sure if you realize your own paradox. Is churn really so prevalent? You then point out how prevalent it is in the .NET community.

Yeah it’s prevalent, and if we resemble other shitty ecosystems then we need to introspect.

Re: Do Not Follow JavaScript Trends

#232

Post by runawaybottle »

hombre_fatal wrote: post #73
runawaybottle wrote: post #17

Earlier quoted context omitted.

But do we get it? If we get it, why is frontend churn so prevalent? I don’t think we get it.

All client-side development churns. Because it's hard, it runs on user devices in the field. And client development is not a solved problem. It's more a moving target of constant research because client devices aren't static either. It wasn't long ago that touch screens didn't even exist. The whole Apple client-dev ecosystem is still in the process of changing to Swift, and Apple is trying to develop SwiftUI into a c…

I don’t think so.

Frontend is knee deep in the process of creating cargo cult devs en masse, and I’m depressed by all of this.

Re: Do Not Follow JavaScript Trends

#233

Post by gfodor »

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.

well, sure. certainly one of the costs of a dynamic language is the possibility of typing bugs, and those will likely grow linearly with the size of the code base.

the question is if those programs were written in statically typed languages, how the world would differ, in-full. for example, they may have been built faster or sloer. or they may have better or worse test coverage, affecting severe defect count overall. or you may have had to hire a different team, with tradeoffs. hard to say.

Re: Do Not Follow JavaScript Trends

#234

Post by blackrock »

throwaway894345 wrote: post #206
mettamage wrote: post #202

Earlier quoted context omitted.

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.

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.

Re: Do Not Follow JavaScript Trends

#235

Post by [deleted] »

quxbar wrote: post #74
christophilus wrote: post #62

Earlier quoted context omitted.

Is front end churn really so prevalent? I hear this opinion all the time, but React is 7 years old. I've been using it for around 5 years, I think. Redux is 5 years old. How old does the most popular web framework need to be before we consider it to be low churn? [Edit: Also, anecdote: before JS, I was mostly a C# developer, and the churn there was at least as bad, maybe worse in my personal experience. Over 15 years…

JS has always been relevant as an ecosystem because it incorporates new ideas. I liked jQuery more than what came before it, and I like React more than jQuery. They make the task of translating an idea into a work app much easier for me, and other programmers I work with also benefit from more readable code. I wouldn't re-write an existing app to use fetch or hooks, but now that I've taken the time to learn, I'm happ…

[deleted]

Re: Do Not Follow JavaScript Trends

#236

Post by wegs »

rowanG077 wrote: post #230
wegs wrote: post #229

Earlier quoted context omitted.

(1) I like generic code which I can use as I see fit later. In Scheme, I can write: (lambda (x) (* x (+ 3 x))) A half-decade later, someone can take that code, pass a pair of specially-crafted objects to it to introspect what it does, and take a symbolic derivative, pretty-print that derivative with LaTeX, combine it with a few other pieces, and compile it into native code (and yes, that does happen). But a lot of my…

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 generate compiled code optimized to the types actually being used. That's a very obviously good idea. And many linters look at inferred types as well to do compile-time checks. That's also an obviously good idea. But I wouldn't call a JavaScript JIT a statically-typed system (or Python code that's been through Pylint).

re: Apples versus oranges

They're not unitless. In the first case, the units are apples. In the second case, they're oranges. You shouldn't compare or add those types. If I do have a type system, that's something I should be able to specify.

Not to mention implicit conversions, if I want them (12 inches + 1 foot = 24 inches).

Re: Do Not Follow JavaScript Trends

#237

Post by nisten »

acemarke wrote: post #180
nisten wrote: post #156

Earlier quoted context omitted.

I would avoid doing state management in Typescript. It's still too early in my opinion. Use as many hooks and context as possible and keep your redux store as simple as you possibly can because if you end up with a deprecated state management library (redux-thunk, sagas, easy-peasy) replacing that is like pulling gum out of hair. If you add up the time spent working around typescript errors when dealing with state, i…

I'm a Redux maintainer, and I'm _strongly_ in favor of using TypeScript for any meaningful app development [0] [1]. Also, I don't know why you're referring to thunks and sagas as "deprecated". Thunks are the recommended default approach for async logic in Redux [2], and we include them out of the box in our Redux Toolkit package [3]. While most apps don't need sagas, they're a great power tool to have in your toolbox…

Sorry I meant as in an older version of a library that an app has been built on and hasn't been updated or maintained for a few months.

I should have put that better, the libraries themselves are not deprecated, their dependencies can be.

While this negligence problem would be on the fault of the dev team and management for not doing regular package updates it is an all too common issue in many companies.

What I am saying is that bad typescript is harder to fix than bad javascript because type errors compound the problems of convoluted code.

Re: Do Not Follow JavaScript Trends

#238

Post by Izkata »

CraftThatBlock wrote: post #221
Izkata wrote: post #189

Earlier quoted context omitted.

CSS Modules didn't become the default way to go until sometime in 2016. Before that point people were still stumbling over how to manage their CSS in a component-oriented fashion, and it was only once that happened did React "win".

CS Modules are still not the "default", this space is still up in the air. There's CSS-in-JS (like styled-components or Emotion), Sass, plain CSS, etc.

They're at least compatible then.

More important to my point, back in 2015/early 2016 and before, you more likely than not had to somehow manually include the CSS for a given component library into your page. Right about the same time CSS Modules got popular, the CSS from libraries started getting included automatically in the compiled CSS file (whether by way of CSS Modules or something else that at least doesn't conflict with it).

I remember this part of the timeline pretty distinctly because late 2015 is when we started a new project in React, and struggled with how to reliably deal with CSS for several months.

Re: Do Not Follow JavaScript Trends

#239

Post by mixmastamyk »

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.

Yes, but easier to just write tests.

Re: Do Not Follow JavaScript Trends

#240

Post by mercer »

mettamage wrote: post #136
wegs wrote: post #118

Earlier quoted context omitted.

Rewrites only make sense if you get a multi-fold improvement. In the history of computing, that's rare. So they rarely make sense. Well, JavaScript was really horrible when it came out. It was just about the worst major programming language ever made. It sort of reminds me of an interpreter I threw together for a programming language I invented when I was in high school, when I really didn't get any aspect of program…

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.

Typescript, for me, makes JS jump from 'good enough' to 'might use it even if I have other options'.

I still prefer using other languages when I can (back-end), but hypothetically, if I had to choose between Ruby and Typescript I'd actually go for the latter. And I like Ruby!

Post reply on HN