Hacker News Reader

Exactly this. All of the upfront choices, will I make the right choice? I've been meaning to jump in and learn. After years of backend development (C#, Python, and some Go), I want to give JS a shot and at least experiment.

It's a daunting process that I keep pushing back as there is no immediate need.

The best thing to remember is that if you're doing it for fun and learning, you don't need anything but a plain old HTML5 and a plain old script tag. Once you feel you need something more than that for a particular project (or for work) you'll be better able to evaluate what's out there.

  <script>
  // get started!
  </script>

even simpler open your browser console and just start typing, I've found new ideas by letting the autocomplete there guide me

This. Someone starting out should not be using webpack, react, jquery, lodash, etc. etc. etc. You need to first learn vanilla javascript which requires nothing more than a browser and a text editor.

Realistically, you won't make the right choice. But that's okay. Because of the number and size of most packages, they are easily replaceable.

Like the commenter higher up said, it's not like C#, Python, or Go where if you have an issue with a library, it could take days to find and implement a replacement. The vast majority of libraries in JS land are small and single purpose. Think of it as replacing the air-filter in your car vs the whole engine.

But that can (and is) solved by either just "picking one of the big ones" and moving on, or by using even more tools layered on top to abstract away a lot of those choices (don't know anything about how to start with react? Just use react-create-app and go from there).

Then a couple years later you've learned a lot of arcane details about something that has already fallen out of fashion. It's not the end of the world but it's not optimal.

Such is life in programming. But feel free to continue using jQuery if you feel all the new stuff isn't worthwhile.

IMHO the sweet spot for picking up new JS tech is about a year or two after it first starts appearing on Hacker News.

> Such is life in programming.

Actually no, the technology churn is much higher in JavaScript-land than most anywhere else.

That is not true at all. It's also not an issue that is going away. This is The Singularity. It's only going to get worse. Either you learn to adapt or you get left behind. And "adaoting" could mean, "learn to quit being a magpie distracted by evwry shiny new thing."

This seems to be true, but I see it as a consequence of how many resources are being devoted to JavaScript by major corporations and legions of developers versus other programming languages. Does Google, MS, Facebook, Apple, etc. ad naseum have entire departments devoted to improving Python, C, Ruby, etc.? Not as far as I know. If there were as many resources being thrown at C as there is at JavaScript I'm sure the churn would be just as high.

React is what 3-4yo now... given Redux is less than 2 years, and there was a LOT of churn on flux-like frameworks. But React + Redux will likely not go anywhere for the next 5+ years, it's already pretty well distilled. Similar tooling and alternatives will still be present, but this happens in any vibrant ecosystem. There was a similar burst in the alt.Net space before ASP.Net MVC and razor came out... even then there has been alternatives introduced.

You're not talking about a single application and platform. You're talking about the most flexible set of cross platform rendering engines ever created. How many UI toolkits are there for Windows, Linux and macOS for native apps, now add Android and iOS... The browser targets all of them, and the base app toolkits pretty much target them all, and still being more flexible and capable than what came before. Expand this to the number of tools available. How could this be anything but echoed in the JS sphere.

Given the shear breadth of Web development alone, let alone server-side, IoT, Desktop, embedded, mobile and who knows where else, how can there be anything but a lot of options and diversity.

That's because "modern javascript" is not there yet, it's still in an experimental phase, we need transpilers and other stuff to use features that are not in a finished state. It will get better with time.

And that getting better process is what people mean by reducing fragmentation.

You're literally contradicting yourself.

"It's not there" i.e its a stinking pile of shit.

that's not correct, and he did address why it doesn't suck. because it's not standardized. some people do better with more complicated things, it's ok to need directions, not everyone does.

your sentences fit in that blog post about a conversation with someone who wanted to build a simple web app in jquery

So when is Javascript not going to be in an experimental phase? A couple of years ago it would have been 'when browsers support ES6'. Now it's 'when browsers support ES7'. Next year it's going to be 'when browsers support ES8'.

To be fair, ES6 was huge. ES7, and probably ES8, are tiny by comparison with only a few new features. Once browser creators get caught up on ES6 it _shouldn't_ be too hard to stay caught up after that point.

But, most of experimentation isn't around the core ECMA features. The experimentation is happening around the toolchain, the libraries, the frameworks, etc. which are separate from stuff like ES6.

Plain old HTML, CSS, and ES5 still work. You aren't forced to install Node and Gulp and any of those things. So I rather much thing the use of the word "impossible" is way out of line here.

They are the foundations, and I recommended them in this very thread. But that's not what most of us would call "modern JS development". The amount of extra stuff between the foundations and current "best practices" is exactly the problem.

"best practices" is just a phrase. There is no objective proof that what people call "best practices" is at all. Far more often, I've seen it used as a protectionism for not learning or trying new things.

Stuff like minification you probably want a pre-existing tool to do. It's stupidly simple and not that difficulty to integrate into any build process.

But stuff like transpiling is completely optional. ES5 is a really high level language. There isn't anything particularly "wrong" with it, not any more so than most any other language you'll end up using.

Start with understanding \JS... then understand ES6 and CommonJS style modules. From there, understand that babel is just a tool to let you use new syntax, which has stabilized a tot since ES6, there's a few bits for async still baking, but that's to be expected. Beyond this is the node-style callback, and more about Promises and async.

These are the core of it all... from there, it's a matter of picking the lego pieces you want to use. What I described above is no more complex than the JVM or extended .Net APIs, especially when you pick all the target options there... in fact the footprint is a lot smaller. Yes, it's a little harder to build something with the 2000 piece lego generic pack than it is with the guided here's a pirate ship with all the parts laid out. But that's what engineering is all about.

If you're really stuck, start with a boilerplate or starter generator tool, there's a few of them for whatever direction you are leaning. Don't worry about picking "the right one"... there is no true path. No matter what you pick, you're going to hit a wall that conflicts with your sensibilities. Angular has the biggest adoption of any web framework ever and only has a 44% approval rating for reuse. That means a LOT of people pick wrong. Adapt, learn, grow...

But for significant pieces of work it is still a hurdle which you must cross. Unless you're writing vanilla ES5 without any dependencies, you have to consider package management, build tools, how to load your modules, before even getting onto transpilation, minification etc.

I can see what's so great about the JS community, but the fixed cost to get to actual production-ready development is pretty high. And rolling your own bootstrapping tools seem pretty pointless given the longevity of any particular tool being the one to recommend. #jsfatigue!

I do a lot of JS development and I think most dependencies are highly overrated. ES5 is a very high level language already. I use a package manager, but frankly, I'm considering stopping because there is a lot of value to being able to just keep a local copy and include scripts with a script tag. It forces you to manually update and inspect for regressions. You get a much better sense of your total payload size, too.

I disagree. All those things you mention are entirely optional and it is very possible to create high quality code without them. My rule is, don't use them until you run into a problem that the tools solve, then you can use them while understanding exactly what problem the tool is meant to solve.

That's what boilerplates, and even generation tooling like yo is there for.