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

101–110 of 122 posts

Re: JavaScript: The Modern Parts

#101

Post by tracer4201 »

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…

Honest question - what’s the point of all this change? At the end of the day, people are building web pages with these frameworks?

John Carmack has an excellent article on static analysis (unrelated to this topic), but there’s this excellent quote:

>It is important to say right up front that quality isn't everything, and acknowledging it isn't some sort of moral failing. Value is what you are trying to produce, and quality is only one aspect of it, intermixed with cost, features, and other factors.

These JS frameworks and build tools provide far more than just code quality, but what all benefits are they providing that outweigh the cost of, “here is XYZ that you must now figure out, and before you can figure out XYZ, you need to learn A, B, and C”. Stated differently, what exactly is the value?

Junior developers make this mistake and unfortunately so many more tenured developers as well. I can understand you want to use the shiny new thing. How often do you replace your toilet or kitchen sink though? Is it worth it?

To me, the JS ecosystem has become to complex. Even if you’re building for Amazon or Google scale, you want to think twice about not only the shelf life of these various frameworks but also what are their dependencies, what are their failure modes, and at the end of the day, how are they giving you an ROI if you use the new X framework of the month or year CS Y.

Re: JavaScript: The Modern Parts

#102

Post by Zelphyr »

rgoulter wrote: post #98
Zelphyr wrote: post #95

Earlier quoted context omitted.

Having a static type system is great but it’s just another tool in the toolbox. I’ve been writing Javascript for 23 years without types and didn’t miss them. They’re great when I have them in other languages but not a deal killer in languages that I don’t. But so many TypeScript fans act as if having types is the be-all and end-all. And, unless I’m mistaken and something has changed recently, I often wonder how many…

"I often wonder how many of the TypeScript proponents don’t realize that they’re mostly only getting compile time type checking" Surely the biggest benefit from static typing is for static-analysis tooling. (e.g. strong compile-time checks).

I don’t disagree but the way people speak about static typing is as if it’s present during the life of the application.

Re: JavaScript: The Modern Parts

#103

Post by csande17 »

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

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

Indeed, hooks are pretty much the furthest thing from functional programming there is. In functional programming, functions can safely be called any number of times from anywhere in the program, and they'll always return the same result for the same arguments.

Hooks, on the other hand, crash and burn at runtime if you call them outside a React component function, or in a different order or number from how you called them the first time your component was rendered.

Re: JavaScript: The Modern Parts

#104

Post by vedantroy »

richardwhiuk wrote: post #68
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…

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.

"It's common among people who think Javascript is a serious language".

I can't tell if you think JS is not a serious programming language.

Re: JavaScript: The Modern Parts

#105

Post by IggleSniggle »

leeoniya wrote: post #76
IggleSniggle wrote: post #28

Earlier quoted context omitted.

46% was the survey number, so I definitely misremembered the facts. But your comparison here is inevitably necessary, since TS compiles to ES6/JSX, (as does Flow)

what was the survey sample size and how was the sample selected? (46% of 0.001% is still 0%). my assessment isn't what things compile to but what they are authored in.

Good question. The state of js survey was self-selected, with 20.2k responses. The data is available if you’re interested. The npm survey, on the other hand, was sent to 800k registered npm users and received 33.4k responses, and also found 46% TypeScript usage. I imagine there is significant selection bias in a number of ways. And, while the state of js survey found 46% “have used ts and want to use it again”, the npm survey did not ask about preference. Still, a decent number of responses that I think is pretty interesting, regardless of your own preferences!

Re: JavaScript: The Modern Parts

#106

Post by IggleSniggle »

leeoniya wrote: post #77
mping wrote: post #19

Earlier quoted context omitted.

I don't understand why jsx is in your comparison, although I agree with your assessment. To be clear there are a gazillion Js projects that don't use react.

it's a bit anecdotal but React /JSX is still more common than TypeScript (if for no other reason than time on this earth). and both are dwarfed by ES5/6

We are writing our React components in TypeScript, so I’m not sure what React/JSX have to do with TypeScript adoption?

Re: JavaScript: The Modern Parts

#107

Post by joewrong »

tashoecraft wrote: post #64
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.

Bazel is the open source version of googles interns build tooling. It’s not new, but using it outside of google is. It’s also not JavaScript specific, it’s completely language agnostic. You define the rules for building, and bazel will execute it. You can run your entire companies build system off of it.

Sounds like Make

Re: JavaScript: The Modern Parts

#108

Post by reggieband »

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…

I happen to be in the interview gauntlet at the moment for full-stack JS type jobs so I hear what you are saying but it seems to cut both ways.

Most places using React are expecting me to be familiar with hooks and everyone using Javascript is asking about familiarity with Typescript. But at the same time they genuinely seem impressed/surprised that I have been using async/await for over a year on my latest professional projects.

I want to say this in a nice way but it is difficult. I feel Javascript developers suffer from an inferiority complex. It's like they need to feel what they are doing is "real code" or something. That seems to translate in this crazy pace of replacement of technologies. I think it gives the impression of innovation. To me it feels like an unsteady eco-system still trying to find its footing. The vacillation from OOP to functional and back again feels like uncertainty. From DIY systems like gulp to all-in-one systems like webpack. It's a sector full of people desperate to look like they know what they are doing while they act like they are still trying to figure it all out.

All that being said, working in JS in 2018/2019 is significantly more pleasant than it ever was in the past. I find creating back-end Node.js services to be quick and easy and writing front-end systems using React bearable. Despite high volatility there is definite progress.

Re: JavaScript: The Modern Parts

#109

Post by ggregoire »

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.

It's not like Python projects are the perfect examples of reliability either.

Re: JavaScript: The Modern Parts

#110

Post by wwright »

joewrong wrote: post #107
tashoecraft wrote: post #64

Earlier quoted context omitted.

Bazel is the open source version of googles interns build tooling. It’s not new, but using it outside of google is. It’s also not JavaScript specific, it’s completely language agnostic. You define the rules for building, and bazel will execute it. You can run your entire companies build system off of it.

Sounds like Make

It covers a lot of the same ground, but IMO is much easier to use all around.
Post reply on HN