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

41–50 of 122 posts

Re: JavaScript: The Modern Parts

#41

Post by quickthrower2 »

Figs wrote: post #24
tus88 wrote: post #2

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

Given how fashion-driven the web industry seems to be, my guess is that some new hotness will steal the stage from it in the next few years. I seem to recall seeing tons of posts about CoffeeScript maybe around 6~7 years ago, but it doesn't seem to be very popular any more... Maybe TypeScript will turn out to have more staying power, but my current guess is that something will happen that makes another technology --…

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 Typescript is 'hyped'. It is popular because it's damn good. As a programming language alone it could be seen as not too special, but when you see what it's trying to do, get JS developers to use types and not run a mile, then it does a brilliant job.

Re: JavaScript: The Modern Parts

#42

Post by siempreb »

egeozcan wrote: post #36
siempreb wrote: post #34

Earlier quoted context omitted.

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

None of the tools you mentioned are unsupported as of now, though. I recently updated a browserify based project from years ago to 16.3 in an afternoon and it just worked. I remember the days I was afraid to do npm update the dependencies, I was copy pasting build script configurations for new projects, I used to use code mods every other month to make huge refactors (and badly), packages disappearing, every project…

> None of the tools you mentioned are unsupported as of now, though.

I mean working as a professional, doing my next gig. Do you think I can still use my Grunt or Gulp skills there? The landscape is now again very different than it was a year ago. I cannot even code in ES6 anymore, all the jobs are TS and React Hooks at the moment. When I say I prefer JS over TS my colleagues think I'm not smart and skilled enough to understand the benefits of TS. There is not much choice unfortunately, independent of being supported or unsupported.

Re: JavaScript: The Modern Parts

#43

Post by siempreb »

azangru wrote: post #39
siempreb wrote: post #34

Earlier quoted context omitted.

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

> 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 officially deprecated, but in practice(again) at company X, you cannot do classes anymore.

Re: JavaScript: The Modern Parts

#45

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…

The thing is, we don't need to learn Bazel either. We will just keep running the command "ng build", and internally the CLI will be using Bazel instead of Webpack, but that is transparent for us users.

We only see the CLI commands on our end, and the Angular CLI internally will use whatever build tool is best for the job at a given time, and will keep evolving over time.

It's such a relief that we don't need to learn build tools in the Angular ecosystem anymore and can focus on application development only.

Re: JavaScript: The Modern Parts

#46

Post by WilliamEdward »

lol768 wrote: post #33

>Whereas Java and C users may still have debates about where, exactly, open source projects should publish their releases, that issue is settled in the JavaScript community I thought Maven Central was pretty much the canonical answer in Java land. Nobody cares what tool you actually use to pull these down (SBT, Gradle, Maven..). >What this means, however, is that to do JavaScript development “The Modern Way”, while a…

Thanks for bringing attention to WebAssembly, far from perfect but with time it could rise to become the default for front ends. Javascript's popularity was purely accidental and doesn't have to be the only option for in-built browser applications.

Re: JavaScript: The Modern Parts

#47

Post by peruvian »

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…

While the JavaScript ecosystem is on the volatile side, learning new tools and frameworks every few years is just part of our job. Only in very boring tech jobs would you only have to learn new things maybe once every 5 years.

I wouldn't really bother wasting time "mastering" something like Webpack or what replaces it - as the other commenter said we just end up using an abstraction over it anyway.

Re: JavaScript: The Modern Parts

#48

Post by wilsonrocks »

siempreb wrote: post #42
egeozcan wrote: post #36

Earlier quoted context omitted.

None of the tools you mentioned are unsupported as of now, though. I recently updated a browserify based project from years ago to 16.3 in an afternoon and it just worked. I remember the days I was afraid to do npm update the dependencies, I was copy pasting build script configurations for new projects, I used to use code mods every other month to make huge refactors (and badly), packages disappearing, every project…

> None of the tools you mentioned are unsupported as of now, though. I mean working as a professional, doing my next gig. Do you think I can still use my Grunt or Gulp skills there? The landscape is now again very different than it was a year ago. I cannot even code in ES6 anymore, all the jobs are TS and React Hooks at the moment. When I say I prefer JS over TS my colleagues think I'm not smart and skilled enough to…

React Hooks doesn't preclude ES6 though?

Really, they're just functions that have some weirdness/magic about when you call them.

I love them, but that's not really what this thread is about, of course:)

Re: JavaScript: The Modern Parts

#50

Post by discreteevent »

peruvian wrote: post #47
siempreb wrote: post #34

Earlier quoted context omitted.

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

While the JavaScript ecosystem is on the volatile side, learning new tools and frameworks every few years is just part of our job. Only in very boring tech jobs would you only have to learn new things maybe once every 5 years. I wouldn't really bother wasting time "mastering" something like Webpack or what replaces it - as the other commenter said we just end up using an abstraction over it anyway.

The problem with changing tools to fend off boredom is that it has a very short lifespan. Pretty quickly your brain realizes that it's not learning anything fundamentally new and it protests. Hence fatigue. If possible, it's better to focus on the problem domain and try to make the best of that for entertainment. If not then maybe just accept that it's better to be a bit bored than fatigued.
Post reply on HN