Things I Regret About Node.js [video]

Post by __s » Thu, Jun 07, 2018, 11:22 AM UTC

LargeWu wrote: post #77

rb808 wrote: post #64

Earlier quoted context omitted.

> The interfaces between server- and client-side code should be well-defined and language-independent. They dont have to be and that is the point. If you write JS/TS front and back you can make everything much simpler with the associated benefits.

But in what specific way way does it make it simpler? What are the tangible benefits? I've been working in a Node/React environment for the last 2 years and there is virtually no overlap between the code we use on front- vs backend projects.

Post by davidgrenier » Thu, Jun 07, 2018, 11:44 AM UTC

vizzier wrote: post #340

manigandham wrote: post #282

Earlier quoted context omitted.

F# with .NET Core? Yes, it works fine. There are some challenges coming up with design changes to the compiler and C# that might overlap what F# already has but it'll get sorted out.

.net core F# support has been pretty great from the initial stages of .net core from my basic usage. Biggest challenge seemed to be around type providers (F# system of generating strongly typed classes from dynamic data such as XML, CSVs, HTTP etc) but that's largely resolved. More info at https://github.com/fsprojects/FSharp.TypeProviders.SDK Great resources for getting started with F# at https://fsharp.org/ My pers…

Post by btschaegg » Thu, Jun 07, 2018, 11:56 AM UTC

Quarrelsome wrote: post #372

rubber_duck wrote: post #369

Earlier quoted context omitted.

C# is very verbose and tedious compared to more expressive languages - having to deal with CLR types/API at runtime while using a language with very limited expressiveness (C#) is not very productive. It's better than Java if that's what you're aiming at - but JVM has an incredible ecosystem of stuff that works - much larger than .NET core which is not very mature in many areas (recently had to revert to .NET 4.7 bec…

> using a language with _very_ limited expressiveness (C#) is not very productive. o_0. Think you need to check yourself mate. I believe the productiveness of more "expressive" language tends to be undermined by the loss of productivity that occurs when you're compelled to write blog posts or comment on hacker news about how amazingly productive and expressive your language is.

Post by jergason » Thu, Jun 07, 2018, 12:19 PM UTC

saurik wrote: post #275

kenhwang wrote: post #261

Earlier quoted context omitted.

Recently, when I use npm, it mostly just works. There's still the occasional node/npm version mix and match to get certain libraries to work and accidental sudo; the former might just be the poor quality of the ecosystem, and the latter is almost just user error. I'd put it par with rubygems, ahead of pip, gradle, maven, a little bit behind mix, and far behind cargo. Not a bad spot to be by any means.

> far behind cargo For the purposes of this discussion, it is useful to note that cargo was written by Yehuda Katz (wycats), who had previously written Bundler, and so actually had some concept of what mistakes he had made before and experience specifically in this area, in order to apparently (I haven't used it yet, but I have heard lots of good things) finally have built something truly great.

Post by noir_lord » Thu, Jun 07, 2018, 12:47 PM UTC

nojvek wrote: post #321

mieseratte wrote: post #306

Earlier quoted context omitted.

> but the only reason for doing so was "my code doesn't look like it does in other languages"... As much as I beat the FP drum these days at work, I find the class syntax a much nicer way of organizing solutions to certain, pardon the pun, classes of problems. Whether or not you find this to be semantic diabetes is a matter of taste, I suppose. I'm curious what, specifically, you find to be the major issue that makes…

ES6 classes were such a relief compared to the prototype bloat you had to right. I love syntactic sugar that makes my life easier. ES6+ flavors of JS & Typescript really made me take web programming seriously again.