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

51–60 of 122 posts

Re: JavaScript: The Modern Parts

#51

Post by ericmcer »

vfc1 wrote: post #45
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…

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…

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.

Re: JavaScript: The Modern Parts

#52

Post by jbverschoor »

vfc1 wrote: post #45
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…

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…

Until you want something that’s a liiitke bit different than what the dev’s usecase was

Re: JavaScript: The Modern Parts

#53

Post by jbverschoor »

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.

It’s not learning a new frameworks and tools. It’s the fact that these tools are usually fragile, and quite frankly not very much new is in there.

Also, what’s your goal? To learn new tools over and over again? Or to crate something that that people will use?

You sound like a music “producer” (read - tech hobbiest) who keeps switching tools, synths, and hardware instead of just creating music.

Re: JavaScript: The Modern Parts

#54

Post by dpau »

jbverschoor wrote: post #53
peruvian wrote: post #47

Earlier quoted context omitted.

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.

It’s not learning a new frameworks and tools. It’s the fact that these tools are usually fragile, and quite frankly not very much new is in there. Also, what’s your goal? To learn new tools over and over again? Or to crate something that that people will use? You sound like a music “producer” (read - tech hobbiest) who keeps switching tools, synths, and hardware instead of just creating music.

Yes, I don't even think the most important issue is that we as developers have js fatigue. The biggest issue is that we are developing web applications that are outdated before they are even released. Our software relies on thousands of dependencies that are constantly changing or even dying off. Updating an application that was built two or even just one year ago is often not a trivial task. So while the frameworks and tooling have thankfully improved, in general the cost of developing and maintaining an application seems to be much greater than in the past (e.g. PHP MVC app with some jQuery sprinkled in).

Re: JavaScript: The Modern Parts

#55

Post by misnome »

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 an intimidating number of incompatible paradigms - and there’s both the technology and toolings.

Easiest to start with one track e.g. react/tutorials and branch from there? Good books that approach the problem efficiently and for a decent existing programmer/scientist?

Re: JavaScript: The Modern Parts

#56

Post by siempreb »

quickthrower2 wrote: post #41
Figs wrote: post #24

Earlier quoted context omitted.

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 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 ideas, wrong libraries, wrong constructs, wrong design principles, tooling hell, etc, etc.. Which is IMHO the real issue with JS/TS. For some reason TS proponents seem to live in a world where 'TS solves everything'.

For me TS is just writing 20% more code and regularly needing to use the 'any' keyword to avoid spending hours on getting a basic line of code working. Everything I write non-professionally is not TS, I cannot think of 1 single reason to give myself that burden.

The best thing TS has given me is even more jobs. With Agile front-end developers spend at least 1 day a week in the meeting room, now with TS they spend 20% of their time left to hassling with types. It's hilarious. Especially all those managers that have no clue what's going on, why front-end development gets slower and slower.

Re: JavaScript: The Modern Parts

#57

Post by pserwylo »

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…

A good high level overview of the moving parts involved in front end dev is https://roadmap.sh/frontend. Not all of it is used all the time, but if you can talk intelligently about many of the parts you are doing fine.

My recommendation to people learning specific frameworks such as react is to start with vanilla react (their doc's are quite good). Then, after building a small app that solves a problem for yourself, you'll start realising when you have bugs and other maintainability issues related to state management. At that point, it is worthwhile looking into redux (or another state management library). Otherwise if you go straight to react + redux it can just feel like a lot of boilerplate for no reason.

Same with TypeScript. I think type safety offers a huge reduction in the number of bugs in large systems. But it isn't required when first learning react.

Re: JavaScript: The Modern Parts

#58

Post by pixelmonkey »

I'm the original author of this post. Was surprised to see this here this morning -- as I expressed in this tweet: https://twitter.com/amontalenti/status/1165252347909607424

Glad to answer any questions about the post here.

I am hoping to write a second part to this post eventually. It was honestly sitting in my drafts folder for a solid 6-8 months, and then I finally cleaned it up and published it two weeks ago. But I still have more thoughts!

Re: JavaScript: The Modern Parts

#59

Post by pixelmonkey »

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'm the original author of the post. A friend who reviewed a draft of it asked me the same question. I had the following recommendations:

1. Solid recorded talk (on YouTube) on using npm run-script to automate local builds: https://www.youtube.com/watch?v=0RYETb9YVrk

2. Modern JavaScript Explained for Dinosaurs: https://medium.com/the-node-js-collection/modern-javascript-... -- this is a long post that goes into technical depth on the stuff that I covered at a high level in my post

3. Webpack -- The Confusing Parts: https://medium.com/@rajaraodv/webpack-the-confusing-parts-58... -- long post that goes into depth on Webpack, in particular.

Aside from all of these, the book I have found the most helpful if you want to zoom straight ahead to React is "Road to React": https://leanpub.com/the-road-to-learn-react

It's 200 pages, oriented around real code, and straightforward.

Re: JavaScript: The Modern Parts

#60

Post by abacadaba »

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…

Annoying, but sometimes a better idea comes along. I think me and many others initial reaction to the hooks presentation was 'yeeaaaassss'. Still in mostly es6 class codebase of course, so haven't had a chance to do too much with them yet, but as long as they're not gonna break backwards compatibility, yes please.
Post reply on HN