Live data from Hacker News

Things I Regret About Node.js [video]

youtube.com

481–490 of 502 posts

Re: Things I Regret About Node.js [video]

#481
post #296

Earlier quoted context omitted.

No, Spring Boot is one of the best examples of the worst kind of terrible patterns in the land of Java development. The bloat in that framework is awful, and the gods help you if something goes wrong in the annotations-everywhere code for anything but the most trivial of applications.

If you limit the annotations to only the basics,(controller,config,bean,requestmapping,etc.) - not much can go wrong. It sounds to me like you haven't worked with any large spring boot apps and experienced the stability annotations can provide.

Except circular dependencies. I work on an app where a circular dependency failure happens depending on what order spring finds our annotated classes. It made writing a faster bean scanner a little tricky because I had to replicate Springs ordering method.

Re: Things I Regret About Node.js [video]

#482
post #321

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.

Or, you know, you could actually learn the language you use. Prototypes are not nearly as bloated as classes, and you usually don't even need them. OO is not the one true paradigm of coding.

Re: Things I Regret About Node.js [video]

#483

Earlier quoted context omitted.

.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…

I'd be very much interested how anyone is using F# on Linux without mono. I have .NET Core but the whole thing seems to require Mono and it isn't clear from fsharp.org that you can do without.

Mono is not required: https://docs.microsoft.com/en-us/dotnet/fsharp/get-started/g...

Re: Things I Regret About Node.js [video]

#484
post #211

Earlier quoted context omitted.

When the only thing you have is a hammer, everything looks like a nail. You’d be surprised at how well screwdrivers work on those funny-looking nails with the threads and the slotted heads. Snark aside: learning a second language is not really that hard, and will make you a better user of the first language in ways that you couldn’t possibly have predicted.

I know plenty of languages, it doesn't mean I want to use more than one for a single project. I don't know what the argument is here. It's not like we're discussing why some no name language is being used, Javascript is prolific to say the least. It's backed by two of the biggest companies on the planet. As much as some wish it would, it's not going anywhere.

The argument is, "just because some of the biggest companies on the planet have started equipping their carpenters with specialized screw-hammers, doesn't mean that they wouldn't be better off using the right tool for the right job".

For my part, I don't want it to go anywhere. Javascript powers some of the most interesting and exciting things in the world of software right now - but that doesn't mean that it's the best solution for every problem.

Re: Things I Regret About Node.js [video]

#485

Earlier quoted context omitted.

I think this is a story that gets repeated lots of times in our world of open source software dev. 1. X is SO bloated and poorly engineered full of bad legacy decisions. 2. We can totally do better let's invent a new thing, Y! 3. Wow, Y is so clean and fast and understandable. 4. But it doesn't do this thing a bunch of people reasonably really need... let's add it. (repeat 3 and 4 a few hundred times) 5. Y is so bloa…

Not everything that gets added is stuff that people reasonably need, either. If you cater to everyone's needs, then you'll end up with 10 solutions for the same problem, because every one of your users has their preferred one. I think Javascript suffers from this quite a bit. ES6 "classes" should never have made it in, for example. Not only did they add an extra level of abstraction for beginners to learn, but the on…

> I think Javascript suffers from this quite a bit. ES6 "classes" should never have made it in, for example.

Well, I'm really happy that the class-statement got in ES6 though.

Before that, whenever I needed something class-like, I had to search how do you do this in Javascript, and find five different answers, no but really which is the proper one for prototype-based inheritance, waste an hour (or more) and frankly I still don't know, there's just so many ways you can do it, which is the RIGHT one? and Javascript wraps in on itself in so many cool ways, but there were never any definitive answers, just more rabbit holes.

Now, there is the class-statement, and it's one less rabbit hole to get trapped in. I actually get more stuff done now that there is one right way to define a class, or class-like object with a constructor, properties, methods, etc.

Similar thing goes for the function arrow notation. Javascript, and the event-based environments it usually operates in, wants you to use anonymous functions a lot. But the relatively verbose way to define them, still held me back from using them freely as much as I wanted, trying to "optimize" them away if possible.

Re: Things I Regret About Node.js [video]

#486
post #425

Earlier quoted context omitted.

Refactor and trim the bloat on the basic libraries, but have a policy where bulletproof automated source rewriting tools are provided in those cases. Perhaps this isn't possible with Javascript, but it might be possible with other languages.

If you think anyone has "bulletproof automated source rewriting tools" I've got a bridge to sell you.

What's the bridge, how much, and is what everyone else is using and/or the next big thing?

Re: Things I Regret About Node.js [video]

#487

One takeaway from this is how Microsoft is killing it currently: * Much-beloved TypeScript * Much-beloved VSCode * Much-beloved GitHub If they hire Ryan to flesh out his vision for deno we'd probably need a new acronym, MAFANG On a more serious note, I wonder if deno could support a lower level construct like Observables. As much as Promises are perceived to be an improvement over callbacks, they still have major fla…

I've already seen the acronym expressed as FAAMG, which is probably more accurate to start with; Netflix has great performance but is nowhere near the market cap of the other companies.

Re: Things I Regret About Node.js [video]

#488
post #467

Earlier quoted context omitted.

The Web has all of these issues and yet importing JS libraries this way has worked just fine. Obviously it's not what you should do if you are publishing a library for others to use, but for local use, and the kinds of exploratory scientific computing he was talking about, it sounds perfect.

It has _not_ worked "just fine" which is why we have bundlers, minifiers, and other build systems.

We have those things as a result of having too much code pulled in from too many sources. This has approximately nothing to do with URLs as identifiers, which is one of the foundations of the Web.

Re: Things I Regret About Node.js [video]

#489

Earlier quoted context omitted.

But this is exactly the way the Web works. Right? And that platform seems to have done alright for itself. For libraries or professional projects, ship your dependencies or use a build system. But for one-off projects, being able to pull in a utility library without needing any tool but the interpreter you're using or some extra build step seems like a big win.

The entire world moved out of inline dependencies in the HTML page to a package managers. We invented bower or npm __because__ of it.

We invented bower or NPM because people thought it was a good idea to have 20MB of JavaScript on a page and 19MB of it written by third parties. Generally speaking, this turns out to have been a mistake.

Re: Things I Regret About Node.js [video]

#490

Earlier quoted context omitted.

Yes Typescript (also from Microsoft) is fascinating and fantastic at combining the strengths of static typing while still maintaining all the flexibility of dynamic types if necessary, however it's pretty much the only realistic non-academic of such a thing, so basically everything else is pales in comparison if that's what you're looking for. Why is C# not expressive? It has the DLR and `dynamic` keyword which behav…

I'm having a hard time understanding what's fascinating about typescript. I agree it makes JS better. I agree it's a good tool for its purpose. But "fascinating" ? It's hardly the most elegant scripting language down there (Ruby, Python, Kotlin and Dart doesn't have to live with the JS legacy cruft). It has a very small ecosystem outside of the web. The syntax is quite verbose for scripting. It has very few data stru…

Typescript IS javascript, so of course it inherits all of its problems. The data structures and standard libraries are what you get from JS, nothing more. It's called a programming langauge but its more of an extension to JS with a powerful compiler.

The typing system is what is special though, especially in how seamless it is in adding strict types alongside pure dynamic objects, but also allowing you to choose pretty much anything in the middle of that spectrum depending on your definitions.

You can have a few strong-typed properties mixed with others in a generic type that inherits from something else but can only take a few certain shapes. It's unlikely you need all that in most programs but it's the fact that you can do it which makes it great. In fact, the Typescript type system is actually turing complete.

Perhaps this video on Typescript from Build 2018 would help: https://www.youtube.com/watch?v=hDACN-BGvI8

Post reply on HN