Live data from Hacker News

How it feels to learn JavaScript in 2017

medium.com

121–130 of 167 posts

Re: How it feels to learn JavaScript in 2017

#121
post #48

Earlier quoted context omitted.

UI is hard dude. It's been a solved (and re-solved) problem for decades.

But has it been solved if you take into account the various constraints/issues: - clients that range from tiny phone screens to full desktop screens - incompatibility when it comes to what features clients support, and even how they support it - a foundation not meant for UI's that is pretty much required to be abstracted away leakily (HTML, browsers) - serious limitations in payload file size for the entire UI codeb…

a foundation not meant for UI's that is pretty much required to be abstracted away leakily (HTML, browsers)

This is the problem, right? It's not that the other problems are unsolved, it's that we're buiding on a lousy foundation. But even that is just an annoyance, something we know how to overcome, it's not a fundamental impossibility.

Re: How it feels to learn JavaScript in 2017

#122

Earlier quoted context omitted.

I've been doing heavy javascript interfacing since the end of the 2000' (it was still a rare skill back then, and made me good freelance money), and I totally understand how you feel. I experienced the same thing when learning angular, flux and redux. It all screamed "overengineering" to me. But then I realized why it was that way, and why it had to be : you now have teams of like 50 js developers working on the same…

How could the 27 file commit example comment not be a clear case of overengineering though? I frequently add similar functionality to Vue and Angular 1 projects in a way close to how you describe and it's simple. Even if the change involved adding a modal library (you should not be wasting time implementing that yourself) to your project first, it shouldn't be more than about 10 lines. Personally, I'd find it very ha…

Yep, I feel the same way, but then again I usually work with small startups. I had an experience with a bigger team, recently (about 20 devs) and went all the way "what you do is too complicated". I was quickly humbled when I realized that my "simple" designs were quickly growing out of control and breaking a lot after a few months so many devs were adding code in it, most of them knowing only a very small part of the app. I guess I could say no product should need 20 devs, but it feels like denial.

So I guess that, to the question "How could the 27 file commit example comment not be a clear case of overengineering though?", the answer would be : "when there are 100 modals in your codebase and various devs work on various parts of those modals". Not saying that's a place I want to work either, obviously :)

Re: How it feels to learn JavaScript in 2017

#123
post #117

Earlier quoted context omitted.

Do you actually code in JavaScript? TypeScript addresses many of these issues and even statically checks for null variable usage which puts it ahead of some mainstream type systems in my opinion. I don't hear people making fun of Python for example and that has a huge following.

I mean, I do occasionally, but I think one big difference is that nobody is forced to use python. If they want a feature a normal language doesn't have, they can easily choose another. That's simply not true for JS.

> I mean, I do occasionally, but I think one big difference is that nobody is forced to use python. If they want a feature a normal language doesn't have, they can easily choose another.

Most domains heavily constrain your language choice though...C/C++ for games, Java/Kotlin for native Android, Swift for native iOS, PHP/Node/Python/Java/Ruby for server-side. The libraries you need constrain the choice even more. I'd love to use OCaml everywhere if I could but there's just no support for it.

Anyway, my point is complaining that vanilla JavaScript is bad is a real disservice to modern JavaScript. What's so bad about it if you use TypeScript?

Re: How it feels to learn JavaScript in 2017

#124

It can be a pain getting the build system up and running but once you're writing typed JavaScript code with modern features like async/wait and ES6 modules along with live + hot reloading, it's impossible to go back. It's really trendy to complain about JavaScript changing too fast right now but the last few years have brought some great changes to JavaScript.

Going back where? Would I go back from JS to Ruby. Without even thinking. Would I go back from JS to Swift? Without the shadow of the doubt. Would I go from JS to Perl? Probably not. But I am sure plenty others would. My quantum mechanics professor told us that "you cannot understand QM, but you can get used to it". Something along these lines applies to JS as well though I am not sure what word should replace "understand".

Re: How it feels to learn JavaScript in 2017

#125
post #52

Earlier quoted context omitted.

A language without a proper stdlib and with programmers who have no idea what the O notation is about has no place in any serious programmer's "to learn" list.

Aka "javascript is not a real language", I thought we were done with that since almost a decade :) Maybe you should consider that just because a language doesn't work like what you're used to, it doesn't mean it's a bad language. Because saying nowadays that javascript is not worth learning sounds pretty absurd. Sure, you can live without it. But that's probably the most useful language to know as a "second language"…

When language does not even have proper integer type I kind of have my doubts about it.

Re: How it feels to learn JavaScript in 2017

#126
post #117

Earlier quoted context omitted.

I mean, I do occasionally, but I think one big difference is that nobody is forced to use python. If they want a feature a normal language doesn't have, they can easily choose another. That's simply not true for JS.

> I mean, I do occasionally, but I think one big difference is that nobody is forced to use python. If they want a feature a normal language doesn't have, they can easily choose another. Most domains heavily constrain your language choice though...C/C++ for games, Java/Kotlin for native Android, Swift for native iOS, PHP/Node/Python/Java/Ruby for server-side. The libraries you need constrain the choice even more. I'd…

I love JS and especially the variety of tools available.

It's a double edged sword. But once you have your tools is great.

I love webpack, vscode, Typescript, npm, preact and mocha. All great tools to solve a specific problem.

So much better than a number of other language. Have you ever dealt with the horrors of package management with pip because it's inconsistent installs.

Re: How it feels to learn JavaScript in 2017

#127

Earlier quoted context omitted.

> Recently picked up a story that was adding a simple confirmation modal to a page: "Alert" text in the top, body with some warning text, and a yes/no button. > By the time all was said and done the PR for this thing had 27 files in it. Can you not just use a library for this and do it in a few lines...? I found Angular 2 verbose but I don't see how the above is common. I just did something similar in Vue today and i…

Or, perhaps instead of a library, use the built in browser confirmation dialog?

You may need modal that contain complex html not only text, imagine a modal that shows a video and a do not show again checkbox.

Re: How it feels to learn JavaScript in 2017

#128

Earlier quoted context omitted.

How could the 27 file commit example comment not be a clear case of overengineering though? I frequently add similar functionality to Vue and Angular 1 projects in a way close to how you describe and it's simple. Even if the change involved adding a modal library (you should not be wasting time implementing that yourself) to your project first, it shouldn't be more than about 10 lines. Personally, I'd find it very ha…

Yep, I feel the same way, but then again I usually work with small startups. I had an experience with a bigger team, recently (about 20 devs) and went all the way "what you do is too complicated". I was quickly humbled when I realized that my "simple" designs were quickly growing out of control and breaking a lot after a few months so many devs were adding code in it, most of them knowing only a very small part of th…

Jesus. Angular is over engineered and not a great tool for your first task.

Use something tiny like preact and you'll probably enjoy the simplicity of it with hyperscript so it's all in js.

Re: How it feels to learn JavaScript in 2017

#129
post #119

Earlier quoted context omitted.

Well, they weren't professional programmers (not their main job, done out of necessity) and they weren't trained. As I understand it they were actually learning it all on the go (like a lot of new programmers). It wouldn't be shocking if a lot of JS devs were in a similar boat, which explains the community a little bit. So yeah, they're programmers now, but they didn't start out that way and the app showed it. That's…

So experienced devs are afraid of learning something that took non-programmers a week to get up to speed and develop a well-architechted app with reusable components etc? I don't buy that, not for a second.

That's not what happened.

We had a set of non-programmers who built a complex jQuery app over a year, which was then translated into a Mithril app over a summer.

What I said was you can be building complex applications in one of these frontend frameworks in a week. Judging from a few responses in this thread, there are a lot of people who don't want to do that for whatever reason.

Re: How it feels to learn JavaScript in 2017

#130

Earlier quoted context omitted.

I like create react app a lot but i wish there was an easy way to add a second page. I tried doing this recently and found it was actually easier to implement react router with code splitting to avoid loading my main page's huge js file.

I always do that, actually. I see what is provided in the App.js file as just a placeholder, meant to be replaced. Since you have webpack, you can import files from all over the place, deciding how to organize your project. It works just fine without ejecting :)

I think the issue the parent is referring to is that CRA's Webpack configs only define a single "entry point", for your index.js, where each entry point becomes a separate bundle in and of itself. Having multiple entry points, like an "app page" and an "admin page", would require editing the Webpack config, which CRA deliberately keeps abstracted and hidden away until you eject.

If you really want to be able to modify the Webpack config for a CRA app, you have a couple other options besides ejecting:

- Create your own custom fork of the react-scripts ( https://github.com/facebookincubator/create-react-app/tree/m... ) package that CRA uses

- Use the react-app-rewired (https://github.com/timarney/react-app-rewired) tool , which lets you override parts of the build config within your project.

Post reply on HN