Live data from Hacker News

JavaScript: The Modern Parts

amontalenti.com

71–80 of 122 posts

Re: JavaScript: The Modern Parts

#71
post #2

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

I'm the original author of this post. I'd say that it's very unlikely that TypeScript will supplant JavaScript. To quote Crockford in 2008: "Because JavaScript is the language of the web browser, and because the web browser has become the dominant application delivery system, and because JavaScript isn't too bad, JavaScript has become the World's Most Popular Programming Language. Its popularity is growing. It is now…

I feel more sold on the ubiquity of JavaScript more than the value of it. I feel sold on the value of TypeScript.

Re: JavaScript: The Modern Parts

#72
No you dont need a transpiler. The new language features are exiting, but its really just old concepts from other languages. And IMHO these old conceps are not better and some of them are worse. JavaScript was lucky and got some things right, like first class functions, prototype instead of classes, function scope, no need for getter/setters. Node.js also got lucky with its module system. JavaScript was lucky because it was async. Javascript got adopted in more then just browsers because it was lightweight. Etc.

Re: JavaScript: The Modern Parts

#73
post #54

Earlier quoted context omitted.

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…

It's blogs and sites like Udemy. Their business model depends on people needing to learn new technologies constantly. So when they tell you "MVC is dead" or "Rails is dead", there is a direct profit motive in it for them. They tell you everyone is using Backbone.js, so you move. Then the next year it's Angular. Backbone is outdated, no one uses it anymore. Then the next year it's React.

The blogs drive the technology shifts in order to get clicks. And every time the technology shifts, Udemy sells a million tutorial videos at $10 a piece. Everyone gets up to speed on the new thing just in time for the blogs to find new clicks and Udemy to find new videos.

Meanwhile the real world still runs on Laravel, Rails, Flask, and Postgres.

Re: JavaScript: The Modern Parts

#74
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.

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.

Re: JavaScript: The Modern Parts

#75
post #45

Earlier quoted context omitted.

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.

> 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, concatenate, minify, compress, etc. like every other project.

Any additional build steps besides bundling are usually very simple can often be done either via npm scripts, or a simple shell script.

Can you give examples of things for which you would absolutely have to customize the build system?

Re: JavaScript: The Modern Parts

#76

Earlier quoted context omitted.

> In 2019, the majority of js developers that take surveys use TypeScript. TS is quite popular, but this cannot possibly be representative of the general population of js devs, not even close. it's more like ES6 >> JSX >> TS >> Flow.

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.

Re: JavaScript: The Modern Parts

#77
post #19

Earlier quoted context omitted.

> In 2019, the majority of js developers that take surveys use TypeScript. TS is quite popular, but this cannot possibly be representative of the general population of js devs, not even close. it's more like ES6 >> JSX >> TS >> Flow.

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

Re: JavaScript: The Modern Parts

#78

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…

It's not like you've been coding with Javascript and now you need to learn Haskell though. Companies love to sprinkle newest trends in their job ads with the technologies they used in their last 100 LOC pilot project and you discover in your first day that there are many big projects which use gulp, grunt and others with ES3, some without async support etc.

I got a friend in Silicon Valley (I'm in Germany and here the attitude is more towards reliability and stability) and even there he got many interviews and a new job without listing many of the newest libraries/languages in professional capacity.

Plus, I'd suggest you try Typescript with an open mind. It's amazing.

Re: JavaScript: The Modern Parts

#79

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.

[deleted]

Re: JavaScript: The Modern Parts

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

> Are you very sure the peak was 3 years ago? Based on what? IMAO the mess only gets worse.

No comment regarding the "peak" but 3 years ago is when the very influential How It Feels To Learn JavaScript In 2016 post came out. https://hackernoon.com/how-it-feels-to-learn-javascript-in-2...

Post reply on HN