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.
How it feels to learn JavaScript in 2016
151–160 of 198 posts
Re: How it feels to learn JavaScript in 2016
#152Re: How it feels to learn JavaScript in 2016
#153If 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.
Re: How it feels to learn JavaScript in 2016
#154Earlier 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).
Re: How it feels to learn JavaScript in 2016
#155Earlier 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).
Re: How it feels to learn JavaScript in 2016
#156Earlier 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.
Re: How it feels to learn JavaScript in 2016
#157Earlier 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.
Re: How it feels to learn JavaScript in 2016
#158See also: https://medium.com/@boopathi/it-s-the-future-7a4207e028c2
Re: How it feels to learn JavaScript in 2016
#159This 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.
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
#160Earlier 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?
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.