Live data from Hacker News

How it feels to learn JavaScript in 2016

hackernoon.com

181–190 of 236 posts

Re: How it feels to learn JavaScript in 2016

#181
post #65

In my experience, the developers who fall into this trap of despair almost always do so because they aren't consciously choosing what tools to use; instead they are letting the tools choose them. They see job descriptions demanding AngularJS or ReactJS and they think that they must learn it, or someone posts an article here and they don't want to feel left behind. Choose a library or tool because it improves your dev…

As someone who learned Unity well enough to do game jams, then tried to switch to Unreal Engine 4 and failed to get traction for a year, I absolutely agree. I was choosing UE4 for technical reasons and completely ignoring my comfort with the system. I was completely unable to get motivated and it absolutely brought my mood down for that year. Then I recently picked Unity back up (and had to learn a year or more of wh…

True story, same issue.

We were building on Unity 4 and kept getting awful looking details and figured 'game engine swap' and went Cryengine. Holy shit, what a bad one. Cryengine and Unreal Engine have well-thought pipelines for asset management and they work great with professional studios that use the complete professional Adobe pipeline. Remember that Unreal Engine is a professional product being shoe-horned for indies where as Unity is an indy product now being shoe-horned for professionals.

Re: How it feels to learn JavaScript in 2016

#182
The frontend frameworks wars are pathological. It's useful, to me, to remember _why_ that's the case: because web sites/apps have to support every browser make and model out there. But how do we know that? Presumably from testing. So its funny that there's isn't any mention in the article about browser testing, or harnesses, or what-not. So now there needs to be another iteration of this series where we step through PhantomJS, Selenium, AWS Device Farm, etc. etc. (and shout-out to Quirksmode and Caniuse).

Re: How it feels to learn JavaScript in 2016

#183

Earlier quoted context omitted.

It makes sense to me. The previous generations had pages that had more rendering on the server and "forms." Now, it's single page applications hitting REST end points. So before, you had complex models, tightly bound back-end controllers, sending data to a view. Now, you have simpler APIs on the server, you arrange and manage the data in the browser, getting more data as needed.

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"

Re: How it feels to learn JavaScript in 2016

#185
post #159

Earlier quoted context omitted.

This is where OP lost me as well. "Oh my god no, no one uses jQuery anymore. You should try learning React, it’s 2016." The appropriate response is "Yeah, your problem seems simple enough. jQuery should do just fine." But that article would be boring and not on the front page of HN.

> "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

Re: How it feels to learn JavaScript in 2016

#186
post #97

Earlier quoted context omitted.

Actually, what people frown upon is using tables for layout. Using them to display actual tabular data is quite fine. (I mean, everything is fine at the end of the day as long as the end-user is happy, but you know what I mean...)

No, you don't understand. I don't want to use tables for layout, I want to use tables to display a good old-fashioned table. A table displayed in an otherwise normally marked up page. That is what's getting the pushback. I guess I could say I want to use table elements to layout a table, which would trigger the "don't use tables for layout" argument.

That's the normal way to do a table. Why import a dozen different libraries to render something that is HTML-included and renders in like 0 time because it's built right into the fucking browser.

Re: How it feels to learn JavaScript in 2016

#187
post #155

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…

That's just it. If all your developers are familiar with at least the basics of React and Webpack, you aren't adding any complexity. Once you know how things work, a simple Webpack configuration with Babel and 2 presets isn't complex anymore.

What would be complex, however, is introducing DOM logic in yet another way. We're all used how you just define the desired state in React and letting it figure out the transitions. When you suddenly ask your developers to write code that manually manipulates the DOM and has to take care of all the transitions between states, you end up with complex, unclear code that takes everyone a long time to understand.

Re: How it feels to learn JavaScript in 2016

#188

Earlier quoted context omitted.

> I've been to more than one interview where I defaulted to jQuery and was immediately disqualified Was the role more biased to front end development? Speaking as someone who has been on the other side of the interviewing table, you won't believe the number of people who can use jQuery but are otherwise unfamiliar with vanilla Javascript. I suspect the question itself could have been solved by via plain JS, and you d…

Oh I'm sure that's not what they mean. 100% sure While knowing how to use vanilla js is important, nobody uses getElementByID anymore, unless you're doing something very, very simple (or building a library yourself)

You sound like the article

Re: How it feels to learn JavaScript in 2016

#189
post #185
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

Effectively React replaces (in many cases, simplifying) the base DOM manipulation aspects of jQuery -- but of course it does not replace the other useful utilities jQuery provides, nor the many DOM manipulation plugins in the jQuery community. When I first started with React I was able to use those libraries without issue -- you do have to learn how (when) React allows you to access the DOM and when it expects you to clean it up but for an experienced dev, its a short learning curve. Over time, I've seen many libraries similar to those jQuery plugins arise (or transition) into React components and its been fine to slowly phase in / out as I please. Lastly, its been mostly straight forward to encapsulate jQuery (or other) DOM manipulation libs within a React component, such that consumers need not even know its being used internally.
Post reply on HN