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!
Oldest comments (240)
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 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.
cheers to the first one!
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.
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
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.
How about this one: Global variables aren't so bad.
@jess does have the best posts
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.
Safari is a great web browser!
cc: @bnb π€ͺ
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.
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 thought I was the only one
Oh we are in the same party!
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.
Sing it loud, brother.
I am saying it louder!
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.
The future is now:
github.com/hecrj/iced
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:
github.com/iced-rs/ios-examples
Notice the build target:
github.com/iced-rs/ios-examples/bl...
This is clearly the darkest timeline.
github.com/Pauan/rust-dominator/ tho.
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".
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.
Virtual Machines > Docker Containers π
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.
venvis 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.)
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.
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 π
aws-cli and boto3 are the worst offenders for botching up an environment.
Dude, I have programmed in python extensively for 13 years and I don't understand what "tabs" are that you refer to. What dependency management compared to C, C++, javascript, etc? NPM dependency hell makes anything in python look quite mild in comparison. I can tell you don't use it often given the shallow opinions expressed.
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
Lessfirst. 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
Some comments may only be visible to logged-in visitors. Sign in to view all comments.