Tell us what your top unpopular tech opinion is ๐Ÿ˜ˆ

jess profile image Jess Lee (she/her) ใƒป1 min read

DEV is in the process of launching a podcast and we'd love for you to be involved! We're recording the episodes in advance, and this week we'd like to know:

What is your top unpopular tech opinion?

If you'd like to participate, please:

  • Call our Google Voice at at +1 (929)500-1513 and leave a message ๐Ÿ“ž
  • Send a voice memo to pod@dev.to ๐ŸŽ™
  • OR, if you don't want your voice recorded...just leave a comment here and we'll read your response aloud for you ๐Ÿ—ฃ

Thank you!


Editor guide

Top unpopular opinion:
I can still be more productive and integrate web apps much faster when using vanilla JS and jQuery than literally ANY JS framework.

Top unpopular opinion 2:
People who only learn full-stack Javascript will have a biased vision on web development


Agreed, but it really depends on the project for me. If I start rendering a bunch of JSON lists I am not on board, but sometimes vanilla just makes things run faster. I was actually converting a vanilla ES6 app to Angular for a research team and noticed a bunch of choppy scrolling. Converted some Angular state management back to some simple DOM queries, and everything was back to normal. Something to be said for that!

Oh, but I won't touch JQuery with a ten foot pole. ES6 minus IE support all the way ๐Ÿ˜


You are 100% not crazy.

I do encourage you to check out Stimulus because it makes it so easy to ensure that your code is mutation-safe, but agree that vanilla really is the best flavor.


Stimulus is awesome!


I agree, depending on the project. It's pure engineering. You have to weigh the advantages of a framework vs the overhead. Folks love to trash jQuery but the simple fact is you can have a project that meets all of your objectives for performance, security, and features with vanilla and jQuery and not spend a ton of time developing it. The end result is a quickly developed quality product. I respect people willing to make a choice like that.


Number 2 especially. The nuts and bolts of http are not going anywhere and you need to get your hands dirtier with that stuff than backend javascript points you towards. Also, back end architecture is a thing for a reason and it's exposed in different ways by more traditional frameworks.


I feel you about the JS / jQuery debate, haha. I ship way faster too, that way. I do feel, however, that I am not improving myself, just repeating tricks. React / Vue force me to organise my code a bit better. Takes longer though, but might be better for scalability and all that.


I'm not sure either of those are unpopular:

It's definitely quicker and easier to do things without a framework up to a certain point, at least.

Anyone who only learns X is going to be at a disadvantage when they play with the other alphabet blocks.


I meant unpopular in the sense that everybody seems to favor using a framework now instead of also understanding that the basic principles still hold. And well honestly I'm trying to learn Svelte now and well I could embedded a Google maps map on a page in 5 minutes using JS for example but in Svelte there's some restrictions on how components are mounted, how files are defined, etc... I wonder if in the end for a similar result, the code won't end up being harder to work with


cheers to the first one!


Python is overrated. It is a weird language, you spend more time organizing tabs than anything else. Not to mention the dependency management, having to do venv and all that. I don't use Python very often (I avoid), but when I have to, I sometimes forget the venv thing and once when using boto3 it messed with my aws-cli installation and I was "what?!". Now aws-cli wisely uses a embedded and completely independent copy of Python, now we know why.


I like python as a language but Iโ€™ve wasted so much time with its bad dependency management and environments. Iโ€™ve tried a bunch of tools that promise to make it better but they always fall short of something like npm.


but npm is even worse, when I'm forced to install npm I look back on python virtual env's fondly.

What don't you like about NPM?

That it routinely screws my whole machine up due to mismatched versions.

Yeah that's a fair point. I use nvm to quickly switch between versions, that makes it much more tolerable ๐Ÿ™‚


Although I do agree that Python is overrated, I never really care about, nor do understand, the indentation hate.

It is overrated because data types and data structures are slow, unless you use some C/C++ bindings, like NumPy. So in the end, it just wraps another language.

Not to mention that the IDE is never as smart as TypeScript, Kotlin or Java.

venv is overrated or not, it might be better than polluting the global installation by default, like Golang or Ruby.

JupyterLab and Conda are cool, but I don't get why it is built into Python.


Small pedantic note: the data types and data structures are slow in CPython, the default implementation. Pypy, another major implementation of Python, is implemented in itself instead of atop C, and performs much closer to compiled languages.


venv is weird haha, check out Poetry for dependency management the next time you're working with Python!


I will definitely try it out, even the Python lovers where I work will adopt if it goes well. I don't think people are in love with venv. hahaha


How about Pipenv and Pipfile are overrated and over-promoted. (Actually, the creator of Pipenv and *for Humans, received a lot of criticisms on Reddit.)


aws-cli and boto3 are the worst offenders for botching up an environment.


Ok, so it's overrated because it forces you to make your code readable and you don't know how to manage dependencies and envs properly.

People would tab their code in the same way anyway, so there is really no time wasted..


I prefer curly braces, it is easier to know exactly where something starts and ends.

You can from __future__ import braces. Haven't you tried. ๐Ÿคฃ

Indentation-based syntax is just another flavor, but limitation to single line lambda is unacceptable.

You can actually use braces with custom encoding. Also lambdas should be trivial. You can always give it a name and declare it as a normal function.

You can see exactly where something starts/ends by looking at indentation, which is easier than looking for braces.

Sloan, the sloth mascot Comment marked as low quality/non-constructive by the community View code of conduct

Calm down. It's his opinion, not verified fact. Smoke a bowl or something.


Working with CSS, especially Flexbox or CSS Grid is 100 times easier than figuring out Bootstrap/ overriding all the Bootstrap stuff you don't want.

Also Firefox > Chrome.


+1 for Firefox > Google chrome.


I do use Chrome but only for it's developer tools which is awesome and to be honest better than Firefox's.


Chrome is great for JS debugging, but Firefox' DevTools really stand out when you're working with the layout. Especially if you're using Grids!

The main thing I'm missing in Firefox Dev Tools is service workers debugging

Yes, this is why I love Firefox dev tools too! I do a lot with the visual side of Front-end and the grid inspector, accessibility, and animation tools in Firefox are great.

Yes I agree completely too, I like working with Firefox dev tools for the visual aspect


I've never tried coding with Bootstrap, but just speaking as a passive consumer of web content, I claim I can spot a Bootstrap website from a thousand kilometers away. Whenever I suspect it, I do some view source, and voy-la, right every time. It's a certain look and feel that is very clichรฉ. Some websites simply scream "Bootstrap!"


+1 for both.

But about bootstrap, the design system sees important if you don't have a design to follow/need to create your own design.


I like Tailwind for styling these days - I find it's better for prototyping than Bootstrap and is less prone to making sites look "same-y".

  • CSS rocks
  • Bootstrap is overrated.
  • knowing CSS rocks
  • bootstrap is fine



I agree with the above statement.




Yes, to both, especially since CSS-Grid and Flexbox exist. ๐Ÿ‘Œ




I agree with your statement.


Docker & Kubernetes are not solution to your scalability problems


I agree, but they're kind of helpful in other ways. Every idiot knows how to docker-compose up for one, and on a good k8s setup you can pretty much create end-to-end applications all by your lonesome even in an enterprise setting: create a new deployment, service, etc., get resources automatically allocated (to some limit), domains automatically configured in F5 (in our case). So instead of writing emails and Jiras for weeks to get dev/test/live virtual machines, firewall holes, permissions, whatnot, I can just get to building stuff.


This. It's basically kicking the can down the road by throwing more money at the problem.


Most unpopular opinion: Memorizing a book of algorithm solutions doesn't make you a better candidate for a software development position, or deserving of more money.


THIS! I actually just shut down a tech test for an agency yesterday because of this. It was crazy, abstract CS algorithm tests that, yes, may have some relevance somewhere along the line. However, I can tell you this: I have been a developer for over 15 years and 90% of your time is spent sighing and wishing that the requirements were fleshed out more before we started building things...


"sighing and wishing that the requirements were fleshed out more before we started building things..." -- echoes the story of my life...



I don't think this is all that unpopular. For one thing, it's verifiably true. For another, I think most young coders would appreciate knowing this before trying to memorize said book of algorithms! :P


Most UN-unpopular opinion then! ๐Ÿ˜


So, it's about the use of strictly typed languages like TypeScript. I think that it's Okay to use JavaScript most of the time however there might be cases when you need strict typing but normally it's not required. Personally, I hate TypeScript.


I mean, if you're not ready to dive deep into Rust, TypeScript is an acceptable compromise for now. JavaScript is a pretty awful experience once you've been developing in Rust long enough, though. Frameworks like Percy, Iced, and Yew are amazing.

Iced lets you write GUI without needing HTML, CSS, and JS. It uses low-level GPU draw calls to WebGPU, Vulkan, and Metal graphics APIs. You can have desktop, web, and mobile builds all from the same codebase. The binaries are highly optimized and 10-100x smaller than Electron.

Percy should be familiar to React and Next.js users. The HTML macros are great, and it can run your application on the server, giving you the best of both worlds. Serverside rendering is one thing, but you can also hydrate and introduce state from your database using context from the request itself, just like the good old days.

WebAssembly is happening right now, and JS and compiled-to-JS languages will never be able to compete due to their reliance on JIT and GC alone.

There becomes a point where it's not realistic to expect your users to have a machine of limitless power to compensate for the deficiencies of your own technical decisions.

The industry is already adopting TypeScript for most new projects. It won't be long until we abandon JS completely.


When will the time come?

I personally don't really care about JavaScript, although I do care about WORA for both desktop, tablet and mobile; and no-installation needed.

It seems to use WASM for mobile.

I am also looking for web browser alternatives, like Expo, actually. But Expo seems not to target desktop apps.

Cordova can integrates with Electron and also mobile, but it seems to reset every time mobile app is updated.

The project is early on, but there's actually been efforts to make it Native. Also, Expo (Fancy React Native) is a terrible compromise, similar to those made by Electron, but exacerbated by the limitations of mobile hardware.

Check it out:


Notice the build target:



Looks neat, but I have concerns. One is, it's not usually necessary to need to install additional Node dependencies for WASM projects. Percy and Iced don't need this. I also don't see an isomorphic (frontend and backend rendering) example. Percy has this. Also, does it support Browser History API routing? I just saw the hashes in the routing file for the todomvc example.

Which dependencies are you talking about?
Just like github.com/ryansolid/solid, there is no support for SSR "yet".
My unpopular opinion for this article is that SSR is overrated.
You can use any router you want, the example uses hashes so that you can try it out with any static file server.
One thing that project desperately needs is better public relations/documentation, such as examples that serve out of the box with one command.
In hopes of which I am raising awareness :v

I recommend checking out Percy and Iced, also. SSR is important because it allows you to be more flexible with your infrastructure. It also helps you support more dynamic values in OG tags, and I'm not sure if Google and others support SSR with WASM apps. Additionally, starting with SSR in mind is just nice because SPAs shouldn't be the prescriptive solution to every problem.

OG is an interesting usecase. I currently spend more of my time thinking about deep web.
Injecting OG tags + standard payload as an alternative to SSR would be fun.
My mind immediately jumps to also injecting an "initial data" bundle at the end of the payload though, and I have to remind myself that that's overengineering.
SSR is a nice-to-have when it's completely free. But it's never free, is it? Even if you are forced to run servers for some other reason, it's all the development effort to keep your data sources isomorphic.
I am not (yet) in the camp of "oh my god, why are you sending that poor person with the metered connection all that markup that they could render themselves", just the "SSR is hard, and there are other, more 'organic' optimizations that you could spend your time on".


This is clearly the darkest timeline.


I think it depends on the codebase and the discipline of the coders. If it is something large with many developers or old and bug-ridden, slowly converting parts to TypeScript may help to identify areas where types are a mismatch and are causing unexpected behavior. If it is a newer/small codebase with a small team and everyone is using a linting tool, then it may be overkill to use TypeScript.

JavaScript codebases can also get some of the benefits without having to rewrite code to use the TypeScript compiler to report on issues. It can be run from the command line or VSCode will report some of those issues automatically.


Yes, exactly that's what I think. Most of the time we have small projects in which we don't need TypeScript per se. I have seen some people emphasizing too much on TS for everything. That behaviour bothers me.


I thought I was the only one


Oh we are in the same party!


Sing it loud, brother.


I am saying it louder!


If you start your projects by asking which SPA instead of why SPA you're doing it wrong.

There's an entire generation of developers who are hive-minded about the idea that monolith = bad, React/Vue = good. They are being lied to because it's profitable for their employers. It's a hegemony and a cult. From the outside, it looks like the inmates are running the asylum.

Seriously: use your favorite stable and proven server-rendered framework, devise a caching strategy where Redis is hot with a >99% hit rate, use Turbolinks to make things load faster than the eye can see, and use Stimulus to manage what little client logic you truly need.


I came down here searching for your comment. That's exactly my opinion.

I'd add that not only this generation of developers, but the not-so-tech and not-so-young managers generation (specially some business tech-ish decision-makers I had to deal with) is sometimes so toxic that I found myself having to throw a buzzword out of the blue, without making any sense, to be taken seriously or have my requests approved. It sounds absurd, but it's true and it works... and that's sad!


Software would be a lot less complicated to develop if you didn't have to use the "industry standard" approach that billion dollar corporations developed to serve billions of users.

And it's pretty clear that developers will martyr themselves for their religions.


Static hosting is cheaper and faster at every level and scale.
Why would you interpolate html on your server?
You're winning nothing, it's not even less complexity.


That sounds like a great strategy, if you're only hosting static documents.

Beyond that, I can loudly declare that I can cast all AD&D 2nd mage spells up to 6th level - but for some reason not the 4th level spells - and have the same amount of credibility as your assertion that I'm "winning nothing".

Seriously, have you ever built anything credibly sophisticated with a server app? I don't believe for a moment that you would voluntarily choose to use whatever nifty combination of Vue + Firebase or whatever you have convinced yourself is best if you could see how quickly we can build reactive applications using Rails, TurboLinks and Stimulus vs maintaining client state and serializing everything as JSON "because better".

Honestly, I don't think your position has a leg to stand on.

That is a view of nothing but pure inertia.
Imagine using last resort hacks like TurboLinks on a greenfield project and claiming you're "using the platform".
Will you have API endpoints? Yes. Will you have some interactivity on the client, including network calls (without a seamless page reload)? Yes.
Why add to that a third thing in a separate language?
And this scales from "one person updating both the API and the UI in one commit" to "here's the GraphQL/Swagger/gRPC spec from the team for that backend feature, use it to generate mocks".
You're paying extra money for servers just to have more things to worry about, avoid scary things like offline-first, websockets, p2p and for what? To say "look, mom, I am generating HTML just like WordPress"?
What's one thing that's easier to do on a frontend server than anywhere else?

That is a view of nothing but pure inertia.
Imagine using last resort hacks like TurboLinks on a greenfield project and claiming you're "using the platform".
Will you have API endpoints? Yes. Will you have some interactivity on the client, including network calls (without a seamless page reload)? Yes.
Why add to that a third thing in a separate language?
And this scales from "one person updating both the API and the UI in one commit" to "here's the GraphQL/Swagger/gRPC spec from the team for that backend feature, use it to generate mocks".
You're paying extra money for servers just to have more things to worry about, avoid scary things like offline-first, websockets, p2p and for what? To say "look, mom, I am generating HTML just like WordPress"?
What's one thing that's easier to do on a frontend server than anywhere else?

Mihail, you've been doing this since 2015. Is it possible that you still have some things to learn? Right now you're equating mature/stable == old/bad. You've come up at a time when it's been super trendy to push everything to the client, and I promise you that this works in a pendulum cycle. Meanwhile, if you keep drinking your own KoolAid, you'll convince yourself that you just happened to luck out and learn the methodology that you're going to fight to prove is the best. It's not a good look, and long term, it's not the hill you want to die on.

Also, this notion that everything has to be done with microservices and all-static front-end everything is just the regurgitation of propaganda. The massive pushback against this march towards the edge is already well underway. I've been building and scaling teams since the late 90s. You don't have to agree with me, but you don't get to squirt testosterone all over the carpet and bleat about how my views are "pure inertia". You're being a dick.

Straight-up, the first and best thing that comes to mind that is easier to do with server rendered UI is state management. You can suggest that Turbolinks is a "last resort hack" all you want, but frankly it's just not a credible statement. Using Turbolinks and a library like StimulusReflex, I can build reactive user experiences that load faster and smaller, render and update faster, and I drastically reduce the complexity of the logic by not keeping any state on the client at all. It's a breeze to develop, it's easy to employ Russian doll caching, it's actually a lot of fun, and gosh, it's good enough for 6 of the top 10 YC companies of all time.

Honestly, everything I do with Rails, TurboLinks, StimulusReflex and Stimulus, I can build it faster than a team of JS devs. I'm not sure that I believe you've ever actually tried these tools, or you wouldn't be saying what you're saying.


How about this one: Global variables aren't so bad.


Good that weโ€™re using languages without concurrency ๐Ÿ˜‚


This is nuclear: I love to use HTML and CSS in a multi page application, the way they did it in the 2000s. It's simple, easy and fast for the user.

I can make buttons without JavaScript by using <form action="nextpage.html">, and Netlify Analytics doesn't require any JavaScript to be included in the page. Javascript is render blocking, but HTML is fast and beautiful. It's pretty easy for me to maintain a 100 on Lighthouse, PageSpeed, Pingdom etc. with an HTML first philosophy.


I don't get why use <form> to make buttons? You can just style a <a> with css to look like a button and not break accessibility.


I run my website through the wave test for checking accessibility and itโ€™s never said form action to change pages is a problem. Can you explain why this breaks accessibility in your view? Iโ€™d love to learn something new.

I'm not an accessibility expert. But the simpler the better for screen-reader.

<form action="page.html">
    <button type="submit">Click</button>


<a href="page.html">Click</a>

What's make you prefer the former one ?


I really like this approach. No overhead whatsoever!


(Controversial?) unpopular opinion: Linux is overrated. For regular end users, it is overcomplicated and not particularly useful. And Linux users many times behave like the tech version of vapers/vegans/CrossFit. ๐Ÿ˜ณ


As a Linux regular end user for years before programming and a vegan myself, I think you should meet new people. ๐Ÿ˜


I should! I like meeting new people... especially if they like hating on Linux ๐Ÿ˜œ

Now seriously, I don't have anything against Linux, I used it for years at a personal and academic level (Mandrake/Linex/Ubuntu). It is ok for servers/development, but I don't see it as an option for the average user.

Maybe it depends on the person and/or Linux distribution. I have never been great on system administration but once I got used to Linux it was more comfortable than Windows (which I find overwhelming!).

It is rather funny to see that assessment, seeing how many computer illiterates, many of them seniors, whom I've trained to use Ubuntu (in 15 minutes, no command line). They are not only proficient at using it even still, but vocally recommend it to others.

Not to say your opinion is invalid, Alvaro. :) Just maybe not wholly objective?

My opinion is completely subjective (and unpopular and controversial, seeing the comments ๐Ÿ˜Š). It's more anecdotal, based on my personal experience, and heavily conditioned by the distributions that I used: Red Hat was a pain to set up (we even had a whole lab at school to do so); in Mandrake, when something went wrong, it went really wrong (and things went wrong often); Linex and Guadalinex were fun (there are some cool projects in Spain where they use them to introduce seniors in rural areas to technology); with Ubuntu everything was easy (compared to the others, it is the less Linux-like version of Linux); ...

Maybe if I had only tried Ubuntu first, I would have a different overview of Linux. But my first experiences with Red Hat and Mandrake were not that positive and they conditioned my view of it. There are a lot of distributions of Linux and not all of them are user-friendly.

Heh. Valid. Many distros really aren't user friendly, I'll give ya that!


Arch Linux is like an old car I know how to work on. When Windows breaks in a mysterious way, I have to look it up. I've tried to find the equivalent of journalctl on Windows, but it never seems to tell me anything worthwhile. When things break on Linux, half the time I don't even have to look it up to fix it.

Also, installing software from the terminal instead of having to go to a website and click the download link is a dream. Spotify, Discord, Telegram, all within easy reach with yay.


I'm aware of it. It's nowhere near as good as pacman. Arguably, even homebrew is better. And that doesn't answer my question, where are the system logs? For example, Windows is awful to play games on, and sometimes they crash for no apparent reason. Sometimes the entire system resets. I've tried different graphics cards, taking the side panels off, upgraded to an 850W single-rail 80+ Titanium power supply, and it still crashes playing modern games. How am I supposed to develop on a system I can't even play games on, and there's no obvious way to see what the heck is happening?

Check this: en.wikipedia.org/wiki/Event_Viewer
Your issues don't happen to all people btw

"Your issues don't happen to all people btw"
... I don't even know what to say. Great sense of empathy there.
Software doesn't always work right for me all the time, but yeah, and maybe it's just me, and I'm just bad at computers, and I should just stop doing anything interesting with them and just stick with what I know.
Great attitude, kid. Hope that works out for ya.

I have never said you were bad at computers. Neither I meant to offend you. What I meant, is you cannot blame Windows just because you have an specific issue, because that's it, an specific issue, not all people have. Actually, the majority of people doesn't have it.
I hope it will eventually work for you, have a good day ๐Ÿ˜„


Well, it's actually underrated. The reason that it doesn't have so many GUI apps, just like windows does, is because it has fewer users, so companies don't bother to support Linux. And don't forget about how hard Microsoft has tried to win the desktop battle, by paying/convincing software/hardware companies for exclusive windows support.


Taking into account how spread it is on IT/servers, yes, it is definitely underrated. My comment was more directed at a personal computer level.


Not really overcomplicated, IMO. It just lacks commercial support, both on hardware and software.

But if you don't care about LibreOffice or web apps, and your hardware is perfect (not bad WiFi, mouse pad or graphics), it might be OK for non-techies. You might not even notice the distro, or you can use a highly localized distro.


Do you do any coding directly for linux use though? (eg. CI pipeline configuration, building docker images)?

Because if you're doing that anyway then using it for your day to day work, is actually simpler (because you don't have issues where it works on your CI but not on your local, and vice versa).


Microservices are not the future, nor the present... They are another good approach for some use case, not for all.


I've worked at companies that have a "megamicroservice". It's an API so complex, it is a thousand times more complex because they tried to split it up into a thousand pieces.


I work in a place where we had a monolith, they started to migrate to a microservices architecture, but this went so wrong that now we're thinking about migrating the monolith to a new monolith and just extract minimal functionality from it (something like the Citadel arch I read somewhere)...

Massive facepalm to the wasted time on those microservices...

This has happened literally everywhere.


I prefer writing raw CSS to using SASS. Yes, I'd rather lose nested styles and mixins over adding an extra second to my build time. Sue me ๐Ÿคทโ€โ™€๏ธ


SASS has been on my to-do list for years, but I never really felt the need to pursue it.


Try Less first. It's the same syntaxe as CSS but with nested and variables. You can learn it in minutes.


Once you spend a little time with it learn how to setup and use it can save you lots of time and you will never want to go back to plain .css files. Happened to me. Of course there is some small projects that setting up and running it all the time does not make sense.


I agree, and I made a JS lib to add mixin support at runtime, which tbh is probably worse in the long run, but saves me from cluttering my html with extra classes or needing to build. cssmixin.glitch.me


Programming has very little to do with maths.


I always thought I was terrible at math. I probably still am. I failed every algebra course I've taken. If I wanted to finish my bachelor's, I'd have to pay to take a pre-algebra test. That said, if I were to study anything at this point, it wouldn't be computer science.

Everything I learned about math, I had to learn on my own. I've created game engines and learned algebra they don't even teach to undergraduates. I had to teach myself trigonometry, geometry, matrix math and transformations.

I did that because it was interesting, and useful. Outside of game programming, I don't really ever need much of that knowledge now. Making software is a lot more than writing code. It's better to know how to communicate effectively with your team, know how to learn and ask good questions, and have a good work ethic and sense of professionalism. Your GPA in math matters about as much to me as your GPA in grade school, for all I care. Nobody asks, or cares, where you went to school. Similar to how adults stop giving each other birthday presents, I guess? You outgrow it, because there's more important stuff to do.


Yeah I sucked at math (shit grades, 68% final exam) and was told to pursue stuff more fit for a 'languages guy'. Coming up with how to phrase Google queries earns 90% of my keep.


It has everything to do with applied maths. It has very little/nothing to do with pure maths (e.g. math class). When most people say "I hate maths" or "I'm no good at maths", they mean math class.

Exceptions if you're working on a game engine (calculus, linear algebra) or data analysis (statistics).


Engineering & systems analysis, on the other hand, do have a bit to do with one or more maths.


Absolutely - there are a whole bunch of things you can do with code that involve rather a lot of maths, and that it would alarm me if someone without strong maths skills was attempting. But code itself is just talking to computers, and does not require much mathematics.

Lucky for the likes of me.


Safari is a great web browser!


I know it's still my go-to! Mostly for smooth scrolling and better battery life, but also like that little "reading list" button to save my 50+ unread tabs for later / never ๐Ÿ˜œ


Itโ€™s a great browser to use but not to develop with.


Please tell me you aren't including *Mobile*Safari in that statement.


Most development these days seems to turn to libraries and/or frameworks straight away - along with all the associated tooling. People don't stop and think if something could be done way quicker and more efficiently just using the basics. This leads to bloat, performance issues, and a whole raft of complications that really do not need to be there.

To be honest, this has always occurred and is not really a recent phenomenon. It does seem to be getting worse though. I believe it stems either from laziness, a lack of knowledge, or a "don't care" attitude towards performance and resource use. I think it's exacerbated by the rate of improvement in the capabilities of hardware outstripping our ability to be able to fully utilise them, and a convenience culture of just using "off the shelf" solutions/components without really understanding how they work - just to get something 'out the door' with the minimum of effort


Perl is a good language to create data centric backend processes.
The reputation of the language is worse than it really should be.

I used a lot of programming languages in my developer life, but Perl was not the worst of them.


Perl is a great language, but almost all projects are at least 10 years old. You always end up with spaghetti code in an 10 year old codebase.


Perl was my first web programming language followed by PHP.

Perl was really fast but itโ€™s very easy to write that code.


Front-end unit testing is overrated.


My unpopular opinion: When it comes down to having a great career in tech - we need to play our cards well, and to find that one thing with which we can have an unfair advantage. Using your time and energy to get that unfair advantage in JavaScript / web programming is a hugely misplaced effort.

The web programming world - and especially JavaScript - is a rabbit hole. Like Alice, you'll find it mesmerizing when you go down that path - everything looks surreal and magical. You continue learning, find JavaScript's idiosyncrasies even alluring at times. And yet, you'd think there is some end to this - some place where you feel "I have seen enough".

That's where you're wrong. There are more nooks to explore, more stuff coming up every time you go further. You think, maybe if I just learn these 4 new things, I should be good. But ohhh no, it never is! Spend a couple of years doing side projects and paid courses, and you think you'd reach a stage where you can finally say - "Finally! I know React and Redux completely. I'm totally hireable as a senior front-end developer now."

But nope, it turns out that now your dream company just wrote a blog post on why they think Vue is better than React. And another dream company of yours has decided to chuck Redux altogether and go for Apollo GraphQL. And now you have React hooks that everyone's raving about. Well that's just perfect isn't it. Yet another JS titbit to pick up and master, because I have nothing better to do with my life. Who knows, maybe this time it will actually be enough and I can clear an interview.

And when you finally open your eyes and zoom away from this mad world, you realize that the rest of the universe has moved on to other cool stuff like machine learning, data science, and product design. And you're kinda late to the party. Because you've been falsely lead to believe that the JavaScript party is the biggest in the technoverse.

If you haven't realized it yet, you will one day. And someday when your coworker excitedly pings on the office slack group - "Guys, have you checked out killmealready.js? It is super cool! I'm gonna try it out this weekend "

You're gonna be like, "Cheers mate, lemme know how it goes!"

Anybody else feel me? Surely I can't be the only one?

Moral of the story

JavaScript is easy to get started with, but extremely difficult to get out of, and to get a mastery over it takes ages. It's quite chaotic and volatile, more than anything else in tech.

You're better off getting your unfair advantage by learning these instead:

  • Devops (Docker, Kubernetes, etc)
  • Data Science
  • Machine learning / Deep Learning
  • Interaction Design and product design
  • User Interface Design
  • Product management
  • And honestly, any other language.

Why? Because it's all about the shelf-life (or half-life) value. Every single one of the topics above have arguably a much longer half-life than any JS framework or titbit in existence today. It's more satisfying to learn how to write linear regression or learning about design principles, than learning how "hoisting" in JavaScript works. I mean why would anyone ever do this?!

var a = 20;

What sort of monster would ever do this?! Have you ever encountered such a monster in the wild? I haven't! And even if you do, a simple magic incantation of use strict can undo whatever this monster did. So why the heck am I supposed to know whether some stupid variable floats up to the beginning of the scope, or down, or round and round like a merry-go-round? Why not move on with our lives already and learn something that's actually useful? Ugh!


Well I have a bunch of them:

  • Android is wrong.
  • Global variables are not bad.
  • ReactJS is a scum.
  • WordPress & Prestashop are bad in a very deep multiple levels.
  • Symfony Framework community is mostly toxic.
  • Symfony Components documentation is a maze.
  • Laravel documentation deserves an Oscar.
  • Laravel Lumen is weird. Each time I've tried to use it I reach a dead end and switch back to Laravel immediately. Now I only using it as simple static files server.
  • TypeScript community is mostly religious and irrational about TypeScript.
  • I don't understand the hype about Kotlin. It's indeed true that Kotlin is superior than Java for Android development (IMO) but its design is kinda weird and messy. Also, it's funny that a lot of ex Java for Android devs praise Kotlin for features that were already implemented in web languages years ago. Usually non-web devs mock and hate web languages and do not consider the people who are using them as "real programmer". Apparently because web devs do not manage the memory manually.
  • Get thousands of users first then think about scaling and rigorous optimization. I've once refactored an API and reduced the expenses from about 430$ per month to 40$ per year. The previous dev went insane about scaling and established a complex architecture within AWS. I've refactored the code, database and moved it to a shared hosting, that's it.
  • Because something is created or backed by a big company it does not mean its good, useful or suitable for you. These companies have data centers bigger than your city why don't you have that too? My point is they create or use languages and tools that are suitable for their use cases and teams. That's far from being your case as a solo developer or a small agency.
  • High-end setup makes difference.
  • Languages are good, developers are bad.

The previous statements complement each other and they are obviously my personal opinion. Don't roast me for them ๐Ÿ˜‚


I like how you fully embraced this question.


What do you mean by high end setup?


I meant a setup that promote productivity and multi-tasking yet it keeps you comfortable and motivated for work. Probably you're familiar with such setup for gamers and streamers.

I asked for such setup but got laptop instead :D


The promise of functional programming rarely matches reality. Some of the supposed benefits of it are that programs are more concise and easier to understand (or "easier to reason about"), but I have found the opposite to be true.

In the JavaScript world, I feel there is an overuse of the map, filter, and reduce functions and the belief that less code = concise code. This leads to these being used simply for the looping aspect of them. I think that in order for code to be concise, it needs to provide a clear meaning, but it often does not happen when those functions are used.

  • These are not well-named and easy to understand functions due to their dynamic nature. The function names themselves are ambiguous, which is expected since they are built-in utilities.
  • These functions take a function as an argument which applies that operation to the data. Most times the function is declared right alongside the call to map, filter, and reduce. This means that there is no descriptive function to rely on to aid in your understanding, at first glance, you know there is a loop and some action being applied to the items. To understand further, you have to parse every line of code.
  • If these are used all over the code and do not have any descriptive names, it is harder to understand the code.

See the examples below. It is a contrived example, so it isn't that complex and you could argue that pulling out the function is overkill, but I am just showing the difference between the two methods. If the function that is passed into map, filter, and reduce gets more complex, the harder code becomes to parse and understand. The abundance of map, filter, and reduce being used as a "functional" for-loop can harm the readability of code.

let array = [1, 2, 3, 4, 5];

// Function is defined alongside the map, it is used once.
let newArray = array.map( number => number * 4 );

The example below shows that logic being pulled out into a named function. I believe this is easier to read and understand. I think this is more in line with what is referred to as functional programming.

// This function can be tucked away somewhere and allows for it to be re-used.
function multiplyBy(scale) {
    return function(number){
        return number * scale;
let array = [1, 2, 3, 4, 5];

// Call map with a descriptive function passed in.
let newArray = array.map( multiplyBy(4) );

I think strict functional programming in Javascript doesn't make sense. The lack of built-in currying and parentheses on function calls makes it awkward to write functional code. But, I think applying some ideas from it is useful. The most helpful thing I take from fp in Javascript is keeping functions as pure as possible. I don't mean not using for loops and mutability inside the function, but from the outside, nothing gets changed. Like returning a new array instead of modifying the one passed to it.


Yeah, I agree. Writing pure functions and making an explicit choice to introduce a side-effect is a good concept/practice to incorporate into any code. I also like the ideas of immutability and referential transparency, since those are widely applicable.

referential transparency

Well, today I learned. "This set of functional expressions is referentially transparent" seems like yet another way of saying "this bit o' code has got no side effects," but with more syllables!

More syllables is always better.

Referential transparency actually means that the reference of an object doesn't matter. Only the value is important. That basically means that even items in different places in memory that have the same value are considered the same.

Actually, according to Willard Quine[1], "a mode of containment ฯ† is referentially transparent if, whenever an occurrence of a singular term t is purely referential in a term or sentence ฯˆ(t), it is purely referential also in the containing term or sentence ฯ†(ฯˆ(t))," as in the following example:

(12) Ralph believes that the man in the brown hat is a spy.
(13) Ralph does not believe that the man seen at the beach is a spy.
The main in the blue hat = the man seen at the beach = Bernie Sanders
t = โ€˜the man in the blue hatโ€™
ฯˆ(t) = โ€˜the man in the blue hat is a spyโ€™
ฯ•(ฯˆ(t)) = โ€˜Ralph believes that the man in the blue hat is a spyโ€™.

I need to get more practice drawing lil tridents on whiteboards.

[1]Although ultimately, like many obtuse concepts in CS, we can safely blame Whitehead and Bertram.

Hmm, well I was talking about referential transparency as it relates to functional programming, as opposed to logic, I guess. I hadn't seen that definition before, it's pretty interesting.


When you start to go down the road of transducers, that's when you start to realize it might've been better to have just stuck to a for loop.

And while loops are highly underrated. I've trampolined enough recursive functions to know it's better to just use a while loop and reduce overall complexity-- computational as well as mental overhead.


I will make tons of enemies with this statement, but for me machanical keyboards should be banned from offices.

In my dev-room we are up 20 people, and 19 of us (so, not me) have a mechanical keyboard. The noise is very annoying, expecially when my fellow coworkers go in berserk and start to tap on those damn keyboards at the spead of light. I put my headphones on but I cannot listen to load music 8h straight everyday.

Please, don't use mechanical keyboards


Doing a step back for a moment: there is an inherent problem with open space offices, which mechanical keyboards exacerbate


There's a lot of good research out there that corroborates this.



Also - why do mice have to click? What does that sound really give us? My deaf friend is a damn good programmer.


Why are you all in the same room, anyway?


where should we be?

Why are you asking me? How should I know? Hey here's a suggestion, how about not in the same room, because science (and anyone who's had to sit next to Loud Janice from marketing) says it's bad for you regardless of what kind of keyboard you use?

If the theme here is going from a bad office environment to a worse one, though, there's always having everybody and their mechanical keyboards pile into a clown car:



A satirical ode to the annoyance power of mechanical keyboards: dev.to/v6/comment/p0o2


Bootstrap sucks the individuality out of the web. Everything looks the same.


And if your site doesn't look like everybody else's, it's "old fashioned", "out of date", or "retro".

When I finally figured that out, I started actively ignoring unwanted opinions about my websites. My life has become very free.


actively ignoring unwanted opinions

Your life will become freer once you start ignoring all the other kinds of opinions, too.


Agree and also I put Material Design in it.


Wait, Material Design isn't an Android-specific thing?


Swift is one of the worst languages, with a hardly functioning toolchain and a language full of inconsistencies, and it lacks a shitton of basic features. Objective-C, in comparison, is much cleaner and well-structured.


YEEEEEEEEEEEEES. Tried to mentor some young developers in Swift, which they were only using because of a free remote coding camp. After two months of struggling (me AND them), I finally recommended they drop the coding camp and learn a real language.


What are your top 5 "real" languages?

Can't pick. There are hundreds. My personal favorites are C++, Python, and C, but there's no shortage of languages to choose from.

Honestly, Swift is a "real language", in that it's Turing complete, but the sole reason it's used is because Apple pushes for it. Its features are all borrowed from better languages, and then poorly misimplemented into a writhing mass of illogic. The entire reason they started the Apple-funded Swift coding bootcamps was to try and drum up a new user base. Developers were making a mass exodus from the language in favor of, to wit, Objective C, and portable languages besides.

My crack about "use a real language" was really more about "use a language that has a practical use case, and behavior relatively consistent with the rest of programming." If Swift were deleted, the majority of the coding world wouldn't notice for months, and if the conversations I've seen are any indicator, most of the Swift-trained developers wouldn't care.

Funny coincidence: yesterday I read a super long article about how Google is betting on Swift as the next language for machine learning to replace Python in the long term and some ML researchers seem to agree with the idea: Swift: Google's bet on differentiable programming | Tryolabs Blog.

The article also lists the reasons why they chose it over other more "popular" options.

I've never used Swift, I only know it exists and people use it for iOS apps, so I have no opinion about it :-)


Emacs is underrated and windows - Microsoft, tbh - is overrated


Windows uses aggressive marketing strategies, like majority rules and proprietary lock-in, to the point that people would rather pirate Windows and MS Office.


HTML is a declarative, Turing-incomplete programming language.


That brings me to the question if it's even a programming language? ;) Or wait, no, let's not start that discussion, haha.


Top Unpopular opinion:
Containers and/or microservices are NOT the cure for everything!


Of course not. <sarcasm>Blockchain is.</sarcasm>



you win.


There is not such thing as Jr Dev Ops.


Also, there is no "Dev Ops" positions. It's a practice.

But meh, no hill I'd go grapple with let alone die on. Marketecture and recruiting is not my field. ;)


Maybe React is too complicated.

I think a lot of the appeal of React is how simple it looks at first, has this philosophy of declarative one way data-binding, where it's 'You just write a function and given those function parameters, then you return some JSX'.

Except with the introduction of hooks:

useState acts differently depending on if it's the first render or not
useEffect acts differently depending on if you added the second [] parameter or not.

All of a sudden it's not a simple 'I call this function, I get this stuff'.


Only one?

  1. PHP is not such a bad tool once you've gotten to know it. Certainly no worse than Ruby.
  2. Stack Overflow is a net-negative for software quality, and I blame the site's love of gamification.
  3. Tech hiring is too strongly focused on years of experience with a set of languages/technologies. If you hire strong C programmers, they can pick up any other language, because they understand the basics.

Yeah, I have those unpopular opinions too.


I do like stack overflow but there is a lot of bad code on there.

When it was a newer site it was great to give a good answer to a problem but most problems are solved now with bad solutions.


LISP syntax is superior to the more-ubiquitous infix notation based languages (Python, C++, Java, Ruby, Prolog, etc). Independent of compiler and platform optimizations and features, as a language construct, LISP is truly infinite.


The problem with the FORTRAN-inspired languages isn't infix notation, it's the bureaucratic mess that is operator precedence. APL and J have infix operators without operator precedence, and they're just as infinite as LISP.

Also, what really is wrong with Prolog? You see some infix-representations of expressions in "is" clauses, but those infix operators are syntactic sugars for what are actually predicates like everything else in Prolog. Prolog gets a pass in my book.


"the web" is not technologically synonymous with "the internet", but it is often colloquially interchangeable. the fact that we use this language to describe the most significant technology in the past generation is proof that all technology made in the past 25 years has been carefully designed at great cost in order to make corporations and billionaires richer. otherwise, software would still be sold and not rented, and your computer would talk to your friend's computer without taking a thousand mile detour to some corporate computer that just had to involve itself for some reason.


The demand for programming positions is vastly higher than it should be, and the largest cause for this is because western european style management (i.e. the same method largely used in the US) are poorly setup for leadership in this style of work. Thus, poor leadership leads to an artificially higher demand for work.

By proxy we end up with more duplicative work being done instead of smart work being done to make things actually work better. Prime example, the Internet is setup, used, and developed on technologies that simply weren't actually built for what it now does. It's a morass of poorly performing, inefficient technologies shoved together to provide what we've ended up with. It's great, but it could have been dramatically better. Instead it uses vast amounts of power to get energy to all the devices that have to waste vast amounts of electricity to churn through the processing power to provide the inefficiently built web pages and related content to everybody.

Albeit one probably wants a more bite size popular un-popular opinion. ๐Ÿคท๐Ÿผโ€โ™‚๏ธ


Yeah I've seen companies that sell like 5 different product configurations to a couple hundred thousand clients that have 100+ devs on payroll to maintain it all. It's realistically doable by 1 guy/gal. Really. It is.


CSS and browser JavaScript are overly complicated, and have too many scars of the past, and need to be overhauled.

Node.js is another proof that people linger too much to the past.

Deno might be more secure, but JavaScript / TypeScript syntax is a mistake.

TypeScript is just a precompiled JavaScript, just like JSX or Flow.

Otherwise, V8 is cool, and can bring a lot of performance, at the cost of RAM. (So, in the end, it is bad.)


Although TypeScript is currently just a compiled language, it runs nativetly on Deno. deno.land/


<marquee> is the only useful HTML tag


My unpopular opinion:
People put way too much stuff into Redis.
Most of the time the local memory is sufficient and way way way way way faster! No need to open network connections; whether local or not.


@jess does have the best posts


Microservice and JS frontend frameworks are used too much?

I don't really see the point of using microservice architecture from the beginning in many startups that just started, why not starting with well crafted monolith architecture? It's hard to maintain all the micro services (a.k.a distributed monoliths) with different languages and concerning all the securities, versions, dependencies, etc ... could have just started with well established Rails/Django/etc

JS frontend frameworks:
It's fun to use JS frontend frameworks, but I have seen many web apps that don't require heavy user interactions use heavy JS framworks/libraries and they are so slow ... and since the frontend has so many dependencies and requires constant updates ... could have just started from server-side rendered HTML, CSS, JS and progressively add stuff as needed.

just an opinion :)


Database triggers are good. There are legitimate concerns about visibility and how they're used, but the most common complaint -- "you're putting business logic in the database!" -- ignores that the database already encapsulates and structures business logic to begin with.


If all the triggers are nicely documented in your migration files and your test suite uses a real DB, why not really?


I have few of these:

  • Python is way overrated
  • There is no such thing as a truly full stack web developer
  • Your app will most probably never reach a point where you need to care about scaling (also, using languages which are easier to scale won't protect you from having to roll up your sleeves)

I've truly done absolutely every technical thing in a tiny company. In a bigger setting it's a waste to be full stack since you're obviously better off focusing.


Someday javascript would crash the world.


Ideal developer for an early stage startup in my opinion is the one who is:
Smart(slightly negotiable) + Passionate(non-negotiable) + Physically fit(who can take some mental beating every now and then without falling sick).


XML, including JSX and HTML is overrated. Better use a simpler closing syntaxes, like Groovy, or no-closing at all, like Pug.


I LOVE Pug. Wish it was used everywhere.


Modern web development is broken. We spend too much energy on tools and building globally rendered apps that have server/client states.

Developers now learn frameworks, but the reality is JS is getting so good, we may not need them as much.

Bottom line, users devices still take a long time to parse JavaScript, but developers are a little isolated with fancy dev machines to see how poor the site loads for many. When a bundle size blocks a quality application, it really makes me wonder why we force presentational component into JS bundles and hydrate state for then.


1) Bitcoin is not about blockchain technology.

It's the cure to a highly pathogenic financial establishment!

2) NoSQL solutions is tech debt on a whole new level!

3) Remember the editor wars? Emacs won!


Functional programming is the best paradigm


Top unpopular opinon in my opinion:
You don't need an analyst or tester for your enterprise application development process .A software developer can do all of the stuff and a lot of money can be saved!


"Enterprise Software Application Development Process". ;)

If you cut those positions you might as well be scrappy overworked startup!


C++ had some awesome ideas that more recent OOP languages should steal.

  • References (not nullable) and pointers (nullable)
  • Const modifiers on methods and parameters to guarantee the underlying data wouldn't change
  • Templates for meta programming, and getting more work out of the compiler

Kotlin is almost there too!


Unpopular opinion:

ORMs are more of a hindrance to your code base than a boon. They work for simple applications, todo-lists for example, but the moment you introduce layered complexity you will hit limitations. Furthermore, I'm highly sceptical any libraries that try and make arbitrary assumptions over how data in an application should be modelled.


Data mapper for the win ๐Ÿ”ฅ