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

JavaScript: The Modern Parts

amontalenti.com

Post reply on HN
Print view View original

81–90 of 122 posts

Re: JavaScript: The Modern Parts

#81

Post by [deleted] »

vfc1 wrote: post #75
ericmcer wrote: post #51

Earlier quoted context omitted.

Sure... I have never heard of Bazel, but it sounds very black boxish (JS goes in bundles come out!). That is basically the same thing webpack promised in comparison to gulp/grunt. A lower config JS build tool, which is always great until it isn’t. At a certain maturity you will need to dig into your projects build tool.

> At a certain maturity you will need to dig into your projects build tool The command "ng build" takes in typescript and produces optimized lazy-loaded bundles, and there won't be the need to customize that, there aren't a thousand ways to produce bundles after all, there is one optimal way for a given ecosystem, and it does not make sense for each project to reinvent a build system that all it does is transpile, co…

[deleted]

Re: JavaScript: The Modern Parts

#82

Post by kontorlaore »

misnome wrote: post #55

It looks like an interesting light summary of the state of things. The technical articles might be more useful, for me. As a primarily Python/C++ developer who dabbled with JS in the early and late 2000s, can anyone recommend an efficient way to get started with modern JS development for hints like interactive frontends with a different-language. I’m comfortable with large language ecosystems, but there seems to be a…

I had the same problem as you.

I also highly recommend "Modern JavaScript Explained for Dinosaurs" for a high level overview of why the JS tooling is like it is.

This is also a good overview of the whole ecosystem, together with suggested learning paths:

https://frontendmasters.com/books/front-end-handbook/2019/

Re: JavaScript: The Modern Parts

#83

Post by mariopal »

siempreb wrote: post #56
quickthrower2 wrote: post #41

Earlier quoted context omitted.

Typescript solves the biggest issue I have with using JS which is a lack of a static type system. It however does it in a very pragmatic way, giving the closest experience to Vanilla JS you could hope for. You are not learning a new language like you would be with Elm or Reason etc. It has a powerful type inference system that puts C# to shame in places, and in some places I prefer TS to C#. I don't feel like Typescr…

> Typescript solves the biggest issue I have with using JS which is a lack of a static type system. Hmm, the biggest problem with JS is types? Are you sure? I rarely had issues with types in JS. With JS I just used my trusty dynamic type checker at specific places in the codebase, and testing coverage of course even more importantly. But with TS, the codebases I see on a daily base are mostly a terrible mess of wrong…

The biggest problem the parent comment have with JS is not types, as you say, but __a lack of a static type system__.

They are things as different as that you can actually have type problems only in a really typed system (as a static type system). Javascript has a very weak type system, and that's the problem. I think you do not understand that static typing serves to solve other problems in the code, not to solve type problems ... it would be like saying that an hypothetical language needs functions to solve function problems ... and then you say that you never had problems with functions in that hypothetical language (ex: assembler, with very primitives "functions", where you have to save data in register before jumping to code in another memory address).

Re: JavaScript: The Modern Parts

#84

Post by EdwardDiego »

> Yes, it has taken 20 years, but JavaScript is now just as viable a choice for your backend and CLI tooling projects as Python was in the past.

Considering how often Node projects break our build, I respectfully beg to differ.

Re: JavaScript: The Modern Parts

#85

Post by blondin »

tus88 wrote: post #2

What's the view that TypeScript is the modern Javascript?

not sure Anders/microsoft wanted to replace javascript with typescript. the problem is this imo.

to use javascript -- or say python -- in an corporate/enterprise environment, you need to analyze your code base. static analysis is what worked well and still does but you need types. ofc having types has other major benefits but this is the big one for me at least.

Re: JavaScript: The Modern Parts

#86

Post by blondin »

EdwardDiego wrote: post #84

> Yes, it has taken 20 years, but JavaScript is now just as viable a choice for your backend and CLI tooling projects as Python was in the past. Considering how often Node projects break our build, I respectfully beg to differ.

i agree with the sentiment. i was just thinking about it yesterday. what if there was a pure javascript based system programming language? with none of the event loop thingies?

i mean can we have a normal javascript that compiles to a x64 binary and calls the OS?

Re: JavaScript: The Modern Parts

#87

Post by ericmcer »

vfc1 wrote: post #75
ericmcer wrote: post #51

Earlier quoted context omitted.

Sure... I have never heard of Bazel, but it sounds very black boxish (JS goes in bundles come out!). That is basically the same thing webpack promised in comparison to gulp/grunt. A lower config JS build tool, which is always great until it isn’t. At a certain maturity you will need to dig into your projects build tool.

> At a certain maturity you will need to dig into your projects build tool The command "ng build" takes in typescript and produces optimized lazy-loaded bundles, and there won't be the need to customize that, there aren't a thousand ways to produce bundles after all, there is one optimal way for a given ecosystem, and it does not make sense for each project to reinvent a build system that all it does is transpile, co…

Code splitting, live reload, things that come up like: we have some components that are using react native web, they will be imported into both web and native mobile applications, how do we prevent native sub dependencies of that component from being imported? What if you have multiple bundles but only want angular in one?

Re: JavaScript: The Modern Parts

#88

Post by vfc1 »

siempreb wrote: post #34
vfc1 wrote: post #27

I think today the Javascript ecosystem looks much better than 3 years ago, at the peak of Javascript fatigue. What we had actually was tooling fatigue, and not language features fatigue. Today, with CLI tools like the Angular CLI, we have a ready to use optimized bundle via one out of the box CLI command, so no longer do we have to learn how to configure Gulp or Webpack. I'm very glad that I decided not to learn Webp…

> at the peak of Javascript fatigue Are you very sure the peak was 3 years ago? Based on what? IMAO the mess only gets worse. You just mentioned webpack is going to be replaced?? That's unfortunately very typical for the JS eco system. 7 years ago we had Grunt, then about two years later Gulp, then about a year later Webpack, now apparently Bazel? Interesting, never heard of it, but I still feel fatigue. I spent quit…

Nothing like that has happened in the Angular ecosystem, the API is stable for 3 years, and a pleasure to work with.

I think this obsession with functions and the functional paradigm is counterproductive in the React ecosystem.

Sometimes, the best way to represent something is a class. When you have some data and a series of closely related fucntions that modify the data and are highly related to the data, it's better to use a class.

This hooks API thing is anything but functional, way too much magic. Its stateful programming diguised as functional.

Re: JavaScript: The Modern Parts

#89

Post by fourthark »

siempreb wrote: post #43
azangru wrote: post #39

Earlier quoted context omitted.

> and now ES6 classes and all the rest are deprecated, because Dan Abramov had another idea for again a new design principle that's just less than a year old: Hooks. This is so off the mark it’s not even funny. - Dan did not develop the hooks api - he is also on record saying that people don’t need to re-write their components with hooks - class components have not been deprecated in React

It is indeed not funny, and you're off the mark as well: > Dan did not develop the hooks api I didn't say he developed it > he is also on record saying that people don’t need to re-write their components with hooks So? In my daily work I see it all the time. You think I have a say in that when I have a gig at company X? > class components have not been deprecated in React You've got a point there, indeed not official…

If people won't even listen to the developers of the tools they use, and insist on "out with the old, in with the new" when those developers are pleading with them not to create extra work for themselves... Whose fault is that?

Re: JavaScript: The Modern Parts

#90

Post by giancarlostoro »

paulryanrogers wrote: post #74
richardwhiuk wrote: post #68

Earlier quoted context omitted.

There's a bizarre, naive belief that all programming is web programming. It's patronising and inaccurate, but it's common among people who think Javascript is a serious language.

Not sure who those people are. But I've programmed precessionally in C, C++, Java, and PHP; and I'd say JavaScript is the most seriously intense. Doing anything useful with it requires knowing so much more than just the language part: libraries, platform (browser, server, Electron, etc.), and the company's preferred tooling/frameworks.

Even with just vanilla JS it can get a bit confusing sometimes. I usually spend a lot of time reading MDN when working with JS just to see if I am missing anything obvious.
Post reply on HN