> For any medium web app, by choosing a framework, you will move the mental load of maintaining and bike shedding to thousands of other engineers,
Suppose you chose a framework. Suppose you were unlucky in your choice. Let's say you chose Angular.js in 2014... only to discover in 2016 that something called Angular 2 is coming out, and that Angular.js is on its way on being discontinued, and the migration story is horrible...
Or suppose you chose Backbone in 2012, and then by about 2015 it kind of died...
Or suppose you chose Meteor in 2013. It was quite popular then... until it wasn't.
Or suppose you chose Aurelia, which had its moment somewhere around 2015 or 2016, when Rob Eisenberg was promoting it taking advantage of the dreaded Angular migration story and of a sneaky clause in the React license. Yeah, it's dead now.
And so on and so forth. At least what you write yourself, for the specific purposes of your application, lives as long as the application itself, and is as fresh as ever.
I was still writing and maintaining Angular JS projects in 2020, when I left my old job. It was a worse option than Angular 2.0, but it still worked fine. The documentation still existed.
I was also maintaining Backbone projects.
> And so on and so forth
The web space needed some time to settle down, I'll give you that. The web as we know it is really only less than 20 years old. Technologies took a similar time to settle back when we chose between C, Fortran, Ada and Java (the new kid on the block at the time). If you were _really_ cool, you may also looked into Python.
Engineers had similar discussions back then.
Nowadays, choose React, Angular or Vue and you will have no problems maintining projects 20 years from now.
> I remember when CSS was "invented". After a small amount of time, I could reasonably fit all of it in my head without needing to look anything up. I looked at the CSS for the first codepen example, and it looks like gibberish to me. Should we really have a mini animations programming language in the styling system?
I don't understand this sentiment. If you are not a web developer, and in particular not a frontend web developer, then you probably aren't building html elements with these fancy effects. And if so, then why does it matter what advanced things CSS is capable of?
> Can't this be done with Javascript?
You can totally do this with javascript. You can plop in a canvas, and use webgl to program this effect on the GPU, like a real graphics programmer. You would have to recreate all accessibility features of the html button on your own. Is it going to be easier? I doubt it. But you certainly can.
You aren't the only one thinking this. The surface area and possibilities with CSS amaze me as one of those web developers who had a solid understanding years ago and have returned it recently. The sentiment is a response to feeling overwhelmed and a sense of reduced competence. You can accept it and learn or rail against it. The latter often happens for a while first.
With web development, I've always thought that there is an element missing for many devs: design acumen and appreciation (I need better terms.) Just look at the site linked from this post and you see an attractive personal site. Most devs struggle with these aesthetic elements.
Desktop development is fairly constrained. As an example, devs can make good or bad decisions around use of the toolkit, but it's less of an open canvas than the web. A lot of the expanded scope of CSS can be more easily exploited if you appreciate the design aspects or have designers creating some target design for you. Putting these capabilities in front of devs without those elements doesn't lead to much success which is another factor driving sentiment.
It's like designers are the very first corner to cut. Or the dev is expected to also be a designer. It's a very different skill set. I'll build your mock-ups, or copy the look and feel of something else, but I can't design my way out of a paper bag. My brain just doesn't seem to work that way.
The first example of a good refactor is a meh refactor at best, and possibly a bad refactor. Array methods such as map or filter are not "more conventional" in javascript; they are "as conventional" as for-loops, and arguably less "conventional", given how for-loops have been around since the introduction of the language. They are also inevitably more expensive than for-loops (every cycle creates an anonymous function; a map followed by a filter means another iteration of the array). The original example was fine; there was no need to "refactor" it.
Disagree on this. filter and map are much more readable and especially extensible than result-arrays. Plus it eliminates out-of-bonds indexing.
See the variable name. It's forced to be 'result' so that it's consistent with the result-array style. Therefore it lacks a descriptive name.
For the functional methods, you can easily assign the filter(age > 18) result to an intermediate variable like adultUsers to make the code even more descriptive. Useful when you have more steps. With the result-array approach, you'd have to repeat the looping code or bury the description deep in the loop itself and so you usually avoid that.
> In all seriousness though, this is a bad question for exactly the same reason as "Please describe your greatest weakness" is a bad question. You're only testing the verbal intelligence of the person your talking to and they are, without a shadow of a doubt, going to give a diplomatic say-nothing answer if they have any sense in them
But why? Why would you not expect an answer like "our website is slow, and we are hoping you can help us with that"; or "we are thinking of improving collaboration between front-end and back-end engineers; and we were wondering what your experience has been in this area", etc?
Firstly because an HR would never know such details (assuming we're talking about first interview which is almost always with an HR), and secondly most people never want to admit any fault, not only their own but the company's.
> “How is your experience working at the company? Can you tell me about the company culture?” ... If the interviewer gives a vague answer, dig deeper: “Can you give me an example of how the company culture manifests in day-to-day work?” This can help you move past generalities and get a better sense of what life is really like at the company.
If you are interested in what life is really like at a company, why use vague abstract concepts such as "culture"? Especially if the company has multiple engineering teams, and you are interviewing for one of them, it is quite possible that the "culture" differs from one team to the other. Why not ask something like "how does the team communicate on a daily basis?", "do you use practices x, y, or z?", "what do you expect from a new hire on this position?", "what are your most important values in the area of tech for which you are hiring?"
As an acceptable compromise we can separate all punctuation and put it at the end of the paragraph Although some oldfashioned enthusiasts of the Chicago Manual of Style will object But I think its good to bring some fresh ideas to our old and worn orthographyevery now and again,.-…’—.
Or write an entire book without them, then publish a second edition with an appendix of just punctuation marks, for the reader to place wherever they feel is appropriate. Oh wait... Timothy Dexter already did that... https://en.wikipedia.org/wiki/A_Pickle_for_the_Knowing_Ones
reply