How it feels to learn JavaScript in 2016 • Hacker News Board

Re: How it feels to learn JavaScript in 2016

#191

Post by ci5er » Tue, Oct 04, 2016, 4:12 PM UTC

moosey wrote: post #185

ci5er wrote: post #159

Earlier quoted context omitted.

> "Oh my god no, no one uses jQuery anymore..." I've been told that within the last month, almost in those exact words, here on HN. I asked what one should use instead and the answer was React. It felt like one of those "no one goes there anymore, it's too crowded" kind of moments.

The official react tutorial uses jquery for $.ajax[1]. I'm really not well versed in any of these technologies (but came up with a fun personal project that might end up using them) so I'm assuming that using both together is tame, and that the venn diagram for the two projects doesn't overlap too much. [1]: https://facebook.github.io/react/docs/tutorial.html

I'm lead to believe that either jquery isn't useful for dealing with virtual DOMs, or that it does screwy things when working together with a virtual DOM system (like react) or both.

I've also heard claims that React's theory of slow DOMs is wrong. Which doesn't make it a 'bad' framework to make use of, just optimized on the wrong thing. I haven't had time to suss this out. I spend a lot of time in "good enough for now" mode because I'm not a dedicated front-end person.

Re: How it feels to learn JavaScript in 2016

#192

Post by callumlocke » Tue, Oct 04, 2016, 4:12 PM UTC

Kequc wrote: post #155

Ambroos wrote: post #121

Earlier quoted context omitted.

I'm sorry, but once you feel comfortable using React there are very few things that React would not be a good fit for, however small the task. I started coding in JavaScript two years ago, right at the point React was gaining popularity. I made a gamble going for it 100%, and since then both the company I was working at back then and the one I started working at recently have fully switched to React for all new front…

I feel that you are marginalising the amount of complexity you are adding to projects which might not need it. There are multiple routes toward completing the same task in development. My concerns surrounding additional complexity I feel are well founded, there are costs associated with such a thing. If all you are doing is DOM manipulation, without doing a huge amount of it, that isn't such a complex task that it sh…

> the amount of complexity you are adding to projects which might not need it

If 80% of your projects are written in X, it's probably simpler to just use X for everything, even things that don't need it

Re: How it feels to learn JavaScript in 2016

#193

Post by dasil003 » Tue, Oct 04, 2016, 4:17 PM UTC

AtheistOfFail wrote: post #183

dasil003 wrote: post #170

Earlier quoted context omitted.

Rails is perfectly well suited to serve an API. In fact I believe it was the first to define off the shelf RESTful conventions for an entire controller and all verbs by default back ~2007 if I recall. http://edgeguides.rubyonrails.org/api_app.html

Actually, Rails 5 implements an API mode so you can spin up a new app with only API-level conventions that runs on less memory and just serves JSON. You can add on the standard Postgres DB and Boom! "You just made Rails great again"

Right, that's what I linked to ;)

Re: How it feels to learn JavaScript in 2016

#194

Post by alistproducer2 » Tue, Oct 04, 2016, 4:30 PM UTC

I've always been of the mentality to use a tool only when the efficiency gains outweigh the learning curve. This is, of course, impossible to judge without spending a lot of time understanding exactly where your efficiency bottlenecks are.

The truth is, a complex application is going to be complicated no matter what tool you use. I look at application programming like this: the more complicated it is, the more likely it is that you've missed key requirements early in the process. This means you will likely need to refactor, rearrange, add/remove features, etc. Choose tools that make this inevitable process as quick and painless as possible. For me that's the number one goal.

I reject tools that make picking a project back up a week or two difficult because of dependencies or weird hacks, syntaxes, or configurations that worked fine when they were fresh in your mind but required an hour of your life to retrace how you got there using the tool.

For example, I chose to use a library that used generators to eliminate callback hell in a screen scraping project of mine. I did this for no other reason than it was too hard to modify the scrapper when everything was nested 8 levels deep. I didn't know what generators or coroutines were before that, but I had spent enough time with my problem to know that I was going to hit a serious maintainability wall unless I found a more clear syntax to write my app. In that case, it was worth the inital overhead of learning new parts of ES6 and programming language concepts.

Re: How it feels to learn JavaScript in 2016

#195

Post by mattmanser » Tue, Oct 04, 2016, 4:34 PM UTC

pauljaworski wrote: post #173

mattmanser wrote: post #137

Earlier quoted context omitted.

Why would you need to say you're using ActiveRecord or Ruby if you said you're using Rails? You've missed the point of the article. Also, will everyone decide in 6 months times that, hmmm, you know what Ruby sucks and we should all start using BooRuubie next year instead? Because I guarantee at the absolute minimum one of the technologies you mentioned will be out of favour this time next year. Also, I can practicall…

You didn't answer his question. What stack do you prefer to use?

Purposefully, as it's utterly irrelevant to the discussion on whether a stack is complex or not.

Re: How it feels to learn JavaScript in 2016

#196

Post by throwmenow_0139 » Tue, Oct 04, 2016, 4:34 PM UTC

raverbashing wrote: post #26

throwmenow_0139 wrote: post #20

It's easy to show how complex those systems are. It's easy because they are complex. And that's pretty normal. Let someone talk about Java Enterprise development, the symptoms of your body and their diagnoses or just try to explain how to build a pencil ( https://en.wikisource.org/wiki/I,_Pencil ). We're professionals, after all, and TypeScript and React were not build by some teenage hackers. I think the problem is…

> We're professionals, after all, and TypeScript and React were not build by some teenage hackers. Overall correct > The reason is that we started to build complex applications instead of enhancing grandma's blog using jQuery.animate, get over it. And this is where we disagree Complexity is needed sometimes, needless complexity only brings the overall value down If I want to do a website using Django I need to get: D…

I agree to your sentiment that needless complexity is bad, technical debt is a real thing and it is plain reckless to use something for the sake of it.

But the term "complexity" gets used in two different meanings in your comment:

a) complexity of usage: You make the point that Django is easy to use, but it isn't simple software; it contains an ORM and is huge.

b) complexity of the system: Django is a complex system. If you are not using any of its benefits, it has needless complexity and you may be better off with a simple PHP script.

And this brings me to the conclusion that it's all about your use case. If you don't build a big SPA, you can get away with vanilla JS without using a transpiler or even a build pipeline.

The reason it's simple to develop something with a full-fledged framework like Django is that they have build a complex system to abstract all those complexities you don't have to think about anymore.

And I don't get your argument in regards to express.js because this is entirely a software architecture decision and they decided that a modular approach suits them well - maybe it's actually less complex for them to develop the software that way because they isolated the body-parser and other components. It's like comparing monolithic with micro kernels - it's all about trade-offs and the added complexity from a developers' point of view may be worth it for the specific use case. There is no general definition of "needless complexity", because the need is very subjective and different for each project.

Re: How it feels to learn JavaScript in 2016

#197

Post by jdauriemma » Tue, Oct 04, 2016, 4:35 PM UTC

dasil003 wrote: post #174

jdauriemma wrote: post #163

How it feels to learn parallel parking in 2016 "I want to parallel park in that parking space." You'll need a car first. "When I was a kid I just walked into the parking spaces." Yeah, but that's not really parallel parking, you were just walking into a parking space. "Oh ok. So I'll get a car then." Well, it's not that simple, you have to actually get inside the car in order to parallel park. "What? Can't I just pus…

Just because you put words in that format doesn't make this a good analogy. You can teach someone to drive, including parallel parking in a couple of hours and then they just have to practice. The javascript ecosystem is legitimately complex. You can't just hand wave that away with a rhetorical flourish.

I agree that the JavaScript ecosystem is complex, that's why I said it in my comment. I'm just making fun of the notion that we should expect simplicity when web development has never been simple.

I have JavaScript Fatigue Fatigue.

Re: How it feels to learn JavaScript in 2016

#198

Post by jdauriemma » Tue, Oct 04, 2016, 4:41 PM UTC

dasil003 wrote: post #174

jdauriemma wrote: post #163

How it feels to learn parallel parking in 2016 "I want to parallel park in that parking space." You'll need a car first. "When I was a kid I just walked into the parking spaces." Yeah, but that's not really parallel parking, you were just walking into a parking space. "Oh ok. So I'll get a car then." Well, it's not that simple, you have to actually get inside the car in order to parallel park. "What? Can't I just pus…

Just because you put words in that format doesn't make this a good analogy. You can teach someone to drive, including parallel parking in a couple of hours and then they just have to practice. The javascript ecosystem is legitimately complex. You can't just hand wave that away with a rhetorical flourish.

Part of the reason why people can learn to drive in hours is because they have been riding in cars as passengers since birth. Though new at driving, they have lots of contextual knowledge and awareness. If you took someone who grew up on a desert island and taught them to parallel park, it would take considerably longer.

Likewise, experienced web developers have years of contextual knowledge of CLIs, documentation and coding. An experienced dev can reasonably be expected to bootstrap a JavaScript app within a few hours, even if they only used jQuery in the past.

Re: How it feels to learn JavaScript in 2016

#199

Post by murukesh_s » Tue, Oct 04, 2016, 4:43 PM UTC

drostie wrote: post #140

hemancuso wrote: post #83

Earlier quoted context omitted.

How would you suggest developers actually figure out what tools to use? It is next to impossible to make an informed decision without digesting a good portion of what the OP is talking about. You need to start somewhere.

This is kind of a cop-out, but I am constantly surprising coworkers with the (I thought simple!) things that I do with relatively old-school JS. I think if you're just starting out on a project -- any project, any skill level -- then your biggest obstacle is your own inertia, your tendency to evaluate options for how you might solve the problem, rather than just plunging right in and saying "I am going to code someth…

100% agree with the point "start out with this sucky stuff and then choose your framework based on what you learn about your pain points, rather than the other way around."

Re: How it feels to learn JavaScript in 2016

#200

Post by jiaweihli » Tue, Oct 04, 2016, 4:57 PM UTC

There's no need to jump straight into the deep end of tooling.

An iterative approach works really well here - do a brief survey of what tools there are and what problems they solve. Then, when that problem starts soaking up a lot of time, you can read up on the available tooling in greater detail.

There _are_ a vast amount of libraries in the js ecosystem, and it'll take time to fully understand all the different pieces. It took me nearly 2 years to achieve an understanding of most of the buzzwords in that article (and even then, there are some I still haven't worked with directly).

In my personal experience, learning JS is very much a BFS process.