I tweeted this yesterday and the response was not good.
Tell me your unpopular opinion. Lighthearted only.
For further actions, you may consider blocking this person and/or reporting abuse
Read next
Show us your open-source Project
Antonio | CEO at Litlyx.com -
Up and down again: A missing feature in front end event propagation?
𒎏Wii 🏳️⚧️ -
How to Flirt with a Developer: Learn to Debug Your Love Life
Sukhpinder Singh -
Performing Backups in Linux: Tools and the 3-2-1 Strategy
ispmanager.com -
Top comments (310)
CSS and HTML are sufficient to build 99% of all websites.
Add a little bit of Vanilla JS. that's it
Like the sprinkles on a cake... 👍
Your web server is coded in HTML and CSS? How does that work? 😜
David was talking about web*sites* ;)
Indeed, a server is the difference between a text file (containing HTML or otherwise) and a web*site*.
OH DEAR LORD, YES.
True , maybe a javascript and json file reading for content and thats it you dont need a fancy stuff.
Super high coverage testing is sometimes a waste of time 😬
💯 coverage is usually an indicator of highly coupled testing, which leads to very fragile tests, which leads to the tests being turned off...
Which leads to anger, anger leads to hate, and hate leads to suffering.
For every metric, there is an equal and opposite metric.
Test coverage is good to know and track, but it can hide problems if it isn't a factor considered alongside a lot of principles and qualitative decision making.
Yes exactly; test coverage isn't the goal in itself and I think sometimes focusing too much on a percentage coverage is a distraction from creating an actual robust pipeline.
See also: snapshot testing in the frontend. Very easy to achieve close to 100% coverage with tests that are easily ignored and overwritten when they fail 🙄
Who writes the tests to test the tests?? 😵
Coast guard.
Mutation testing
100% coverage of low quality tests is so much worse than 20% critical tests.
Many, many times.
That said, if you are publishing libraries that are meant to be reused (e.g. on PyPI, or NPM), 100% is often a good idea.
Full Stack Devs really exist.
What is a full stack dev? A "jack of all trades"?
Yes, we exist. I design, write markup, styles, and handle back-end code and design database models.
But can you solder? 😜
One of the fun games to play with people who call themselves full-stack devs is to see just how "full" their stack is. So often it's just a bit of JS and PHP.
I can solder 😂😂
Exactly, I have also seen bad examples of full stack. But that doesn't change the fact.
I ask because I think people use the terms "front-end developer," "back-end developer," "full-stack developer," "Java developer," etc. in different ways.
Sometimes an "XYZ developer" term seems to describe the skill set possessed by a developer, and other times it is used to describe the specialization area of a developer.
When talking about skill sets, the term "full-stack" makes some sense to me: it emphasizes that a developer has learned a little about a lot and is comfortable diving deeper anywhere, including new territory.
But when talking about focus areas or areas of specialization, I think the term "full-stack" can be confusing: it seems to say "I'm good at everything," but a) that's not true, and b) every tech stack is different.
Also, the terms "front-end" and "back-end" refer to different things depending on if we're talking about web development or not.
Personally, the only modifier I tend to use with the terms "developer" and "engineer" is "software." Anything more feels like I'm putting myself in a box, and it might be hard to get out of later on.
"I'm a software engineer with ___ experience using ___ technologies, and I want to learn more about ___ by working on ___." More verbose, perhaps, but also a more accurate characterization of myself.
I think you've hit the nail on the head. Web Devs too quickly silo themselves into front or back-end and limit themselves to understanding only part of the product they're working on.
So often I've seen features implemented in the wrong place in the stack. Not because the Dev was bad, because they didn't want to learn a language on the "other side" of the stack.
This should be more than doable for an average Dev (being multilingual is, after all, a thing) but for some reason the REST API seems to represent a cultural divide between the front-enders and back-enders and us full-stack Devs are viewed suspiciously by both.
SOLID, TDD, Agile, all apply to both "sides" of the stack. It's certainly possible to be a good Dev on both sides - so long as you don't measure being a good dev as simply someone who can remember all the native functions in that language.
I think that while they do exist, they all tend to have a specialty and, more importantly, relatively important shortcomings. I've yet to meet an actual full-stack that doesn't suck at one part of the stack, be it CSS, server configuration, DevOps, whatever.
Myself included. I suck at doing responsive layouts.
This is not so uncommon. There are a lot of people who can program the client all the way to Assembly. The question is, is this an efficient way to work in a project?
Depends.
If your team and project scopes are small, hiring "full-stacks" make sense. There simply wouldn't be enough work for a full-time front-end developer in many places.
However, I've also seen places hiring a full-stack in hopes or getting rid of the need for an actual front-end developer for their product. Or hiring front-end devs who can use Firebase in hopes they won't need a back-end.
This rarely works, and when it does, it does quite poorly.
Devs can build their portfolios on WordPress
This is a great one.
Wordpress isn't exactly an "elegant solution" these days, but it is a hardened one with basically every use case imaginable covered. Any user-facing flaws can be overcome with tooling and config, same as any comparable software.
It's also very useful to learn Wordpress. The company behind Wordpress just raised another $300m. The software isn't going anywhere any time soon.
True Ben.
Headless Wordpress with Gatsby kind of well optimised frontend will be a killer combo for mid sized projects
Use cases,
Can second this. Been building a full-stack app for a few months now using WP as the backend + GraphQL API and React Frontend. Also use some serverless functions to supplement functionality that can't be done in WP.
It's been amazing because as a single dev, I can work on what would otherwise be a huge/impossible project by leveraging WPs' CMS, authentication features and plugins.
The only thing slowing me down is the WordPress GraphQL ecosystem is still almost non-existent
I'm going to be looking into Gatsby and next.js this year. One question - how do you handle updates on Gatsby when a post or something else is updated in WordPress? Do you have a hook/action that is triggered and posts to gatsby to run a new build?
I used wordpress once in 2003 but I haven't built a single wordpress site ever since!
I recognise what people have done with it, and it's maturity as a platform, but I count myself lucky!
I've had one on WP for years now. I'm switching to hosting everything on a GitHub pages site. It's just far easier to maintain with little effort. Helps focus on writing rather than messing with a WP set up.
Too many plugins, not enough code I can modify without fear.
Mine is even more primitive. I use a static site generator. Lol
It's 5pm I want to go home.
Yea. People are working themselves hard. I think some people are worried about their prospects or they really love their job.
It would definitely be the prospects. I've worked with companies that do have a good balance though.
Yea. There are nice ones. Just that there're more bad ones.
The nice ones probably have more competition and don't need to hire as often since the turnover would be low.
That's true. I got an email from a company that I interviewed with a year ago. Before I set up an e-commerce website. And they have all three roles open again. Turn over maybe... What do you think?
I don't think most companies need employees that badly. They just want more for extra growth.
They aren't closing without them.
That's a good point. Could you explain in more detail?
I mean they can still operate without hiring more people.
Just that they might not have as much output.
Oh I see. That makes sense. Thanks for explaining that in more detail.
My boss makes a point of telling us he doesn't pay overtime. When I first started I was staying until 6-8 PM. Absolutely not worth it.
Not paying overtime is pretty normal. But staying that late definitely not normal
But did your contract have that clause which states working extra hours to get the work done?
JavaScript is well-designed: most of us simply don't use it effectively and too frequently blame the tool for our problems.
It honestly irks me a lot how people cite the infamous
0.1 + 0.2floating point arithmetic error as a justification to ostracize JavaScript (even though most programming languages suffer from this issue as well by virtue of floating point limitations).Like, seriously? Are tiny nuances really that evil so as to dismiss the programming language altogether? No, right? Python suffers from the same error, but is nonetheless one of the most loved languages out there.
You are definitely correct about people not using it effectively. When people write arguments against the languages, it's always because they don't use it right, as in non-"Pythonic" code for Python.
No, I would cite -- github.com/aemkei/jsfuck
Most importantly,
[1, 2] + [3, 4]that I learnt from Python. I know that there is.concat()and spread operator, but still...Another thing is
varhoisting, but it can be made understand, really.I hope I'm misunderstanding, but this style of example "learnt from Python" always puzzles me. Specifically, why do devs expect things to work the way they do in some other language, rather than learning the constructs in the language theyre presently working in?
I do suppose that the language should be failsafe. Even TypeScript doesn't warn., nor throws an error. Even Python is safer. TypeScript is partly safer, and some part more dangerous than Python, due to JavaScript-based.
RTFM, partly, is OK. But reading the whole EMCA specification is crazy.
Also, I cannot expect tutorials to teach everything.
I also expect the language to be "guessable" rather than being told to do so. Otherwise, throw an error early.
Productivity doesn't wait for you to finish learning...
But knowing additional paradigms might be helpful. Knowledge should add-on rather than replace.
Still, end-in-end, I love JavaScript (not even saying TS), more than Python.
Although it was designed in 10 days (in a way) it is quite simple and good enough I would agree. I just would never use it for backend as I prefer type safety and having some thread control. Dynamic typing and such things could be "shoot yourself in the foot" for some devs and then they blame the tool.
IMO the premise that most users don't use it effectively disproves the assertion that it is well-designed. To me, a language that is well-designed is easy to use effectively by default, and so most people would. I like JavaScript because the platform runs in so many places and there are so many different things I can do with it. This is ultimately not a consequence of good language design, though.
I would amend that it to "popularity and versatility are not necessarily a consequence of good language design." 👍
I suppose we should come up with a definition of "effective use" for this discussion before we dive too far and realize we're not talking about the same things. 🤓
When it comes to effective use, programming languages are quite similar to natural languages: it's all about communication. How well can you say the right thing?
One of the key differences between natural language and programming language, though, involves the audience: natural languages meant to be read by humans, but programming languages are are meant to be read by humans and computers.
So effective use of JavaScript is a question of how well you can balance what you say, such that it is right (for some, and possibly different, definitions of 'right') for both the readers of your code and the machine that eventually executes it.
To be able to find this balance, and communicate effectively with JavaScript, you need to understand the impact saying certain things in certain ways has on both humans and machines.
Language design definitely influences how challenging this process is, and there are some features of JavaScript (some present in the original design, some recent additions of ES6) that make this process harder than it needs to be, but not enough to make me feel it deserves the amount of flak it receives from our community.
Agree, JS is a simple, productive and elegant language with a great ecosystem.
I was following you until "great ecosystem". The whole node_modules thing is mostly a house of cards waiting for the right gust of wind to make everything fall apart, and most of the tooling is mostly over-engineered reinventions of existing tools.
But I really like using the language. It's fun to write in.
I think this is true after ES6 when JavaScript has all the syntactic sugar that other languages like Ruby has.
Also whoever designed it actually thought about what they're changing before actually making the changes.
POC are likely the first production release
¯\(ツ)/¯
Sad but true. I haven't been in the game long, but I feel like the whole "move fast, break things" mantra is often interpreted as "ship your prototypes."
Most software products I’ve seen have at least one feature that just screams “we have a demo on Monday, can you code this over the weekend?” And then that’s what goes to prod because there’s another demo on Friday for some other feature.
Haha yes
"we have a poc, so the Software is already complete. There is only some logic missing!"
Man I think I just found my support group 😢
learned this the hard way
I would love to hear about your experience in this area.
Well latest one was like build this and that and we need demo up in 3 months. Next thing you know always new feature requests and as a must. After that they started talking about release in another 6 months and I was like heeelllll no. They agreed to build prototype and then rewrite the whole thing but I'm sure they think well it's only bug fixing and optimizing. The code is impossible to maintain so hope they understood last time what rewrite means
Scalability can be a premature optimization
It is, always.
Don't need it, yet doesn't come into it.
Agile is rarely implemented properly. It usually ends up as shorter timeframe waterfall with less documentation.
And called incorrectly. We do Agile is like saying We do Green. Maybe Agile Methodologies?
I call it FrAgile because the Agile pieces tend to fall apart pretty easily and then it’s just a poorly planned Waterfall project...
That's just true, not unpopular, just not talked about.
I guess, that's not that unpopular.
Some “do agile“ because they're trying to come across hip, but once you look inside it's (like you said) plain old waterfall in biweekly sprints.
I've started asking in depth about user stories, effort/story points, on time deploys vs overtime hours in interviews and literally every company, even large blue chips are stumbling on it. They don't know their process, they think user stories are a waste of time. But then you ship the feature and everyone is all "damn we can't do X" sigh
Oh yes, wonderfully articulated
OMG, you are 100% correct.
Basic for loops in JavaScript are fine.
Depends what you're using then for. For performing operations on every element of an array or object, Array.prototype.map is really nice. But I definitely agree that for loops as opposed to Array.prototype.map, reduce and for each are never really bad; they're just sometimes not the best.
As soon as you need to have async code in your
forEachcallback you need to switch your code to the for loop again. So if there is any chance this might happen, pick it right away...Nope, you can Promise.all()
How,
.forEachdoesn't collect the returned value, you would need to switch to.mapand there are quite some cases where you don't want to fire all of these things "at once".Then you can use await and Array.prototype.reduce. It sounds a bit awkward but is actually straightforward.
I'm not sure I get your point (or whether you got mine), so I'll put some code:
Independent of using
maporreduceto iterate over an array, the "aaync callback" will return the promise immediately for every item.(Even the function that contains the
await Promise.allwill immediately return with a promise, of course)The implication is that you can not run those async actions in a sequence using the methods provided by
Array.protype.Meaning
urls.map(fetch)is the same asurls.map(async (url) => await fetch(url))and it's not different from usingreduceto create that Array of Promises.But
Will only trigger the second fetch after the first one is done.
I have had plenty of experience where servers have blocked to many simultaneous requests, so it's worth considering the impact the code can have.
(If that's not clear I'm willing to take the time to write a post about it.)
I really don't like seeing people using .map for things not returning a new array. The whole concept of "mapping" comes from functional languages, or even higher, from mathematics, and always have been about "mapping" one set (your input) to another (the returned array). Discarding the output and using map as a glorified for loop makes the intention unclear.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.