Live data from Hacker News

How it feels to learn JavaScript in 2016

medium.com

151–160 of 198 posts

Re: How it feels to learn JavaScript in 2016

#151
post #72

Earlier quoted context omitted.

I'm a content guy who knows enough web dev to be dangerous. I made 3 manual edits to a css file to fix a couple of incorrect background colours in our web content the other day. I was a good boy and made a pull request for those same changes in the git repo. Our developer explained that he doesn't actually edit the css file. He would have to work out the change in the hue (as a percent of the base colour) and update…

> He uses a mac. I use windows. Aaah, good luck. For me it's basically gotten to the point where if the build doesn't immediately work on Windows, I just fire up a Linux VM and work off of that. And that's not just for front-end projects, but for open-source projects in general. Windows support is often really lacking in an environment where devs seem to use Linux and Mac almost exclusively.

That was actually my first response too... I set up the build process on my linux test server while I continued to battle to get it working on my daily drive win10 machine.

Re: How it feels to learn JavaScript in 2016

#152
Like a lot of 21-year-olds, javascript has gotten big and strong, but its brain hasn't finished developing yet. It hasn't figured out what it wants to do with its life. It engages in binge drinking a little more than is healthy. It's sowing its wild oats. Didn't we all when we were 21 (or didn't we wish we did)? It has 3000 Facebook friends. Last year it had a best friend, but now it's hanging out with someone else and doesn't even talk to that other one any more. It's kind of preoccupied with being cool and popular. Young adults can be very self-conscious and anxiety-ridden. Constantly checking its status on social media ("OMG, I wonder what I look like on iOS 10?") probably isn't helping things. Still, it's really smart and helpful and has a lot of talent. Give it time. Cut it some slack. It will find its way, make something of itself, and make you proud. You'll see.

Re: How it feels to learn JavaScript in 2016

#153

If you are sick of javascript on the front end, but don't want to give up the fancy-pants UI, you could do worse than my library, intercooler, which lets you add AJAX to your app with a few HTML attributes. http://intercoolerjs.org Make REST work the way it was intended, supports CSS transitions, request indicators, etc. Good little library that eliminates a lot of complexity for web apps that don't need all this jun…

Just saw intercooler referenced in a post a couple days ago and took a look. It does look refreshingly simple to get started. I've got a basic app with JSON end points already created. I was going to give VUE a go but after looking at intercooler I'm going to create an alternate set of /IC/* URLS and send out HTML instead. I'll soon see how it works for this task.

I'd love to hear what your experience is. Thanks for giving it a try!

Re: How it feels to learn JavaScript in 2016

#154
post #72

Earlier quoted context omitted.

I'm a content guy who knows enough web dev to be dangerous. I made 3 manual edits to a css file to fix a couple of incorrect background colours in our web content the other day. I was a good boy and made a pull request for those same changes in the git repo. Our developer explained that he doesn't actually edit the css file. He would have to work out the change in the hue (as a percent of the base colour) and update…

Sass is awesome, and one of the few pieces of the 'compilation toolchain hell' I _don't_ hate. But you ideally shouldn't have your CSS build product in the repo if you're using SASS. That would avoid the confusion of editing the wrong file (the compiled output artifact, which ought not to be in the repo).

I read this as the CSS was live edited on a production server.

Re: How it feels to learn JavaScript in 2016

#155
post #72

Earlier quoted context omitted.

I'm a content guy who knows enough web dev to be dangerous. I made 3 manual edits to a css file to fix a couple of incorrect background colours in our web content the other day. I was a good boy and made a pull request for those same changes in the git repo. Our developer explained that he doesn't actually edit the css file. He would have to work out the change in the hue (as a percent of the base colour) and update…

Sass is awesome, and one of the few pieces of the 'compilation toolchain hell' I _don't_ hate. But you ideally shouldn't have your CSS build product in the repo if you're using SASS. That would avoid the confusion of editing the wrong file (the compiled output artifact, which ought not to be in the repo).

If there are other things to build for production, sure, throw SASS in too but if not, it's not worth it just to keep your repo "pure."

Re: How it feels to learn JavaScript in 2016

#156

Earlier quoted context omitted.

React is really very simple. It only takes a short amount of time to learn it, and then when you do you won't get headaches all the time trying to keep track of state. You don't need to know all the toolchains and crap if you just use create-react-app.

> You don't need to know all the toolchains and crap if you just use create-react-app. I love the hand wavyness of this! Yes, you DO need to know the toolchain. Because if you don't, it is going to be murder on you if you need to track down why something isn't working. Professional developers need to use professional tools and understand them deeply. There's no compromises here.

While I agree you need to know the toolchain, create-react-app is a professional tool, it works very well. I've struggled before configuring webpack/babel/etc. manually and while it may "murder" me down the road one can always eject if need be.

Re: How it feels to learn JavaScript in 2016

#157

Earlier quoted context omitted.

React isn't that simple. You still have all the package manager/transpiler/build baggage. You still sacrifice pages that aren't blank if javascript is disabled of fails and all the potential SEO/accessibility costs of that. And you suddenly end up with great globs of javascript in a page that might not need it.

None of those things has anything to do with the inherent simplicity of the library itself.

Out of the two simplicities one has an actual impact on usage.

Re: How it feels to learn JavaScript in 2016

#159
post #11

This is pretty much why I don't do front-end. I'm fully capable of it, but I just don't like keeping up with this flavor-of-the-week. It just doesn't feel like programming to me, or at least not the programming I enjoy. Strangely, I see so many new developers rushing toward the front-end, which seems much more complicated in many ways than just building solid web API services, analyzing data, etc.

I am a full stack guy who was doing 50/50 front-end vs back-end till last year. But since then, I've started moving more towards the back end as I simply am not able to keep up with the newer frameworks and libraries coming out everyday.

What is worse, a lot of employers have already decided that if your app isn't written in React + Redux + whatever-is-hot-today, it isn't worth doing. I like to keep my stack fairly simple, and my approach apparently doesn't work.

I still do a fair bit of front-end development, but only when its on my own terms.

Re: How it feels to learn JavaScript in 2016

#160
post #27

Earlier quoted context omitted.

Your use of the word "easier" is questionable. Even for trivial SPAs it's often easier to roll the basic functionality yourself. Flipping over to something like Angular introduces technical and cognitive overhead that often isn't worth the trouble for something simple.

What about maintainability? You want everyone who touches your code to figure out your custom solution for data binding? Or you could just follow the conventions established by an industry popular framework that is instantly consumable by another developer?

But that's just the problem with the modern proliferation. Finding a developer who is proficient enough in all of the frameworks you might be using is difficult. It's not enough just to have a JavaScript developer, you have to specify about 20 frameworks that you are using. It's not possible to train everyone in all of these, so then, even your framework system becomes personal, because it is setup to your personal choices (much like a custom function!). Since new people can't reasonably be required to fully understand the totality of the system, they will still come up with personal hacks, precisely because the set of things to know is too large.

Remember, they don't know which part of the framework you are using or not, or which parts are important or not, so even if you are using it for one little thing, they probably have to learn most of it to understand how it interacts. Since so many frameworks overload standard functionality, it is impossible to know how a framework interacts with your code until you know all of these things.

Using 20 frameworks is about as efficient use of your time as having one you built yourself. The sweet spot for a medium-sized application is using 2-4 (maybe a few more if they are really standard or do really specialized functionality - i.e., a PDF library) for the most critical components, and still maintaining the remaining quirks yourself.

So, for example, Ruby-on-Rails + Bootstrap + JQuery goes a very long way, and doesn't put an undue burden on people trying to get to know your code.

Post reply on HN