I hate that trend of making things more lax in terms of implementation quality while writing it off with a simple but stupid "oh computers are faster now, users have the RAM, yadda yadda". Yeah but back in a day things were actually running pretty damn fast in comparison while doing it on hardware that is totally potato in comparison to what's used now. This trend eats away ANY gains we get in terms of performance with upgrades. It deprecated the whole notion of netbooks (and I kinda liked them for casual stuff), since now every goddamn one-page blog costs you from several megabytes and up to tens of megabytes of JS alone and lots of unnecessary computations. Like dude, you've brought in a whole Angular to render some text and three buttons, and now your crappy blog is chewing on 500 MB of my RAM for whatever reason.

Also, Electron apps. Hate them. Whoever invented the concept, deserves their own warm spot in Hell. You're doing the same you would've done more efficiently in Qt or whatever there is. Qt actually takes care of a lot of stuff for you, so it doesn't look like you'll be slowed down by choosing it over Electron. Like yeah, web version will share some code with your desktop solution but you're the whole reason I'm considering your competitor's lack of Electron a huge advantage over you even if they lack in features.

Same can be said pretty much about everything that tries to be more than it should, really. IDEs, for example, are cancerous. You can do 90%+ of what you intended to do in IDE using plain Vim with *zero* plugins, and it will also result in less strain on your hands.

People have just unlearned the concept of conscious consumption, it seems.

you fucked up with the IDE part

I agree with everything, except the IDE thing

@lamka02sk @neeno why though?

@0x5d0 because IDEs are easy and useful, you have code completion and refactoring actions, those are things you can't have on vim without plugins. If you install plugins, well I'd say they're basically the same thing, but I wouldn't say one is better than the other, it's a matter of taste.
Writing code in vim without plugins is the same as writing code in notepad++, you can do it but you're making your life harder than it should be.

@neeno

>refactoring

Depending on what exactly you consider refactoring, you likely have it in vim-base.

>completion

Tags. You'll probably want to go for something like CoC if you *really* want it to act smarter (i.e. use LSPs for completions) but it works adequately for pretty much anything that's built in.

>same as writing code in notepad++

I could be wrong but it's not modal, you can't reasonably navigate it using home row alone, and worst of all, there are no macros. Also no pipes, no grepping, no QF window, no marks... There's a lot of neat stuff that makes Vim good but these are just off the top of my head. Saves a ton of time and effort actually. I can argue that I can even refactor via macros to an extent: nothing too smart, no actual code analysis but I didn't find myself in desperate need for anything beyond even in large projects.

So again: idk what's the use case for modern IDEs. Probably most people use them for "just werks" without learning the tool.

Bonus point: if I would use plugin-ridden Vim over IDE, I'll still have a freedom to choose what I use.

@0x5d0 I'm not very familiar with vim, just a very general notion of how it works.

I consider refactoring being able to change a class/variable name everywhere it's used, not just replacing the variable name's string where it occurs, I mean semantically searching for where it's referenced.

If you use CoC it's not vim without any plugins any more.

Yes you can navigate using the home row, there are plugins for that. I'm not sure to which extent you can use only the home row, but I imagine a big part of the functionality is available on most plugins.

Idk what vim's macros are, so I can't say anything about that.

It's not "just werks", it's more of "I can't be bothered to spend 2 months coding slowly as hell just so I can learn how to use vim while I have an IDE that does everything that I want with zero effort". As I said before, it's a matter of preference.

@0x5d0 what? And how is that different from using an IDE? You do know you have the freedom to choose any IDE you want and switch it anytime you want, right?

@0x5d0
Serious question though. Suppose I'm running a work chat app on my laptop which is a resource hog and has been made in electron (hint hint). I have 16GB RAM and 1 TB SSD and a powerful enough quad/octacore processor. I open the app, I send messages to my coworkers, do all office stuff. It may be a resource hog but I don't even notice with 16GB of RAM and modern virtual memory systems.

Why should I care about performance and/or consumption when said app gets the job done for me? Should the devs work on improving something that makes no difference to a majority of their users anyway? All dev work has opportunity cost, would you rather do that or add more features to the app that differentiate it from its competitors?

Legit question here, what would you do if you were that chat app's developer?

(And yeah, you've totally missed the mark on IDEs, vim is a totally different thing).

@neeno In regards of freedom of choice, I'm referring to an ability to have a thin base (that still provides a huge API to hack on) and fill it up with some extra parts (maybe "heavier" ones) to your liking. It's pretty much what you do when getting plugins for things like IDEA but you have a much thinner base with virtually no footprint that you can extend with whatever tickles your fancy. Instead of having a lot of stuff you won't even use in a base package, you'll actively choose to get whatever you want to have, thus removing the redundancy.

@neeno The point on "coding slowly for 2 months" is kinda valid though if you don't know your way around Vim. Once you're past that mark, you'll be really productive.

@RememberMe Open up a Chromium-based browser on top, some office utils, and you'll notice what I'm referring to. Seriously though, I'm struggling to get enough headroom even in 32GB when working with some heavier stuff actively. Sometimes these apps also leak memory, so after like 8h uptime working I might end up with a full swap. On a 32GB machine. Bonkers. Killing the browser, every Electron and such, I'll drop the usage to a reasonable amount of 2 to 4 GB depending on what runs in parallel (some really phat Docker images, Docker itself actually deserving a separate hatepiece).

I mean, I could've comfortably done all the same stuff ten years back on something like a 2GB RAM netbook running something like Intel Atom, and I'm not kidding in a bit. Ten years passed, I'm forced to go for a 64GB machine to stay in comfort while working.

On a topic of "what would you suggest", I've said it in the OP. Just go for a native yet cross-platform solution like Qt, it's really simple.

@0x5d0 I do agree having a thin base and extending it to your liking is nice, it's lighter and makes the UI less cluttered. But I don't really care, I have a good pc so everything's fast. I guess a less cluttered interface would be nice though, but meh I'm too lazy to learn and configure vim.

I've tried using vim a couple of times but both times I was too lazy to keep trying to get used to it. One day I'll try again, third time's a charm.

@neeno You can start off with Emacs which is easier to get used to. Did it for a couple of years in the past. Got tired of constant need to Ctrl-X and Alt-X though, figured it's easier in Vi-like editors.

@rutee07 but that's a good thing, right? It's a goal of technology to increase our productivity and output. Nobody does hand optimised assembly any more for example because 1. Compilers generally just do it better 2. Modern superscalar out of order processors are so complex (and so insanely smart in their own right) that you'll probably either end up wasting time or deoptimizing something.

@0x5d0 I'd disagree with native being simpler, it's much easier to crank out features with electron or whatever's the cross platform flavour of the day.

I agree that excessive bloat is bad, to the point of making things unusable is definitely bad. I also agree that there are many apps that have simple unacceptable performance. But then it's also a question of markets. Everything's a trade-off, and if an app is popular despite being a memory hog, it must be doing something right in its market and use case, so my question was more of what would you do *given that you were in that scenario*. Netbooks aren't really a thing that anybody targets anymore, mostly because phones are so usable now.

If I make an app targeting a netbook of course I'll be careful about resource usage, it's just that it's a non relevant market for whatever app you're using.

I'm curious what apps you're using that big down your system that bad, I use a.ton of js based office stuff every day on an el cheapo thinkpad t440 and it does fine? Memory leaks are definitely not acceptable for sure, that's a bug.

Also, what's your beef with docker?

@RememberMe Qt is cross-platform, for instance. And lots of similar solutions are cross-platform, too. You still need to have a matching compiler but that's absolutely not a problem.

As of memory, T480s that I use for hobby projects (as in "no Slacks, no JIRAs" is completely fine, 16 GB are MASSIVE when you don't really run much) holds up OK. Workstation is barely breathing on a nice sunny day with a couple fancy-looking docs open, with the local infrastructure (not a lot, 5GB or so), and JIRAs, Slacks, fancy webpages and such usually build up to eat around 20 to 25GB and more, choking the available space for maneuvers down to 1GB or so. Stuff swaps in, swaps out, 1GB that's left is used for a compiler to do its job, and sometimes an evil OOM killer shoots at tabs.

>beef with Docker

Overused, often unnecessary, lacks maturity but somehow dominates stuff. Also leads to your coworkers bringing in some phat images that will cost you a lot of diskspace eventually.

I agree with everything including IDE but if others want to use it that's cool imo

I'm with the rest about the ide point.

- debugging with smart, conditional breakpoints, allowing the debugger to navigate the code views/tabs/loc. Debugging java, typescript, js. How is that done in vim?

- intellisense which gives me info on the spot I would be otherwise browsing in docs/sources for. And that info is actual, not just some substring-match ^n does in vim. That means I see *accessible* methods of an object both in that object and in its ancestors [superclasses]. Across all the files in the project - but only those accessible by the class I'm in. Does vim know how to do that?

- realtime compilation errors, codestyle warnings/hints. Including highlighting the errorneous parts of the code and giving suggestions on how to fix it. Can vim do that?

- build tools integration to the point where I get warnings/errors/suggestions if I make an error in my code violating module's boundaries, + suggestions. Including customized gradle modules/tasks. How can I integrate gradle into vim?

- spring integration where an ide suggests which beans have not been configured properly and are not reachable in particular parts of the code.

- testing frameworks integration where I can (a) launch a single test case [not worrying about compilation], (b) see in the code which assertions failed, (c) see in an ide which loc are covered by that test case, (d) debug tests with breakpoints

- refactoring code, i.e. moving classes to different packages/modules/subclasses? And update all the references to that class in the whole project [but not to touch classes with the same name but different package]? Can I rename classes/methods/fields the same way?

how can I achieve all that with vanilla vim? Can I do that as quickly as with an idea? Can I easily switch between different setups [capable of all of that] for different projects?

You made some good points, however you don't realise that Electron was there to fill a gap (something Qt and such don't do because they aren't cross-platform), it certainly isn't as efficient as Neutralinojs, Tauri and co (and I wish those would be more popular than Electron) but it gets the job done (although not efficiently enough).

As for IDEs, you missed the mark; not everything can be handled by Vim alone nor is it as approachable or as easy to learn and use as other text editors (most of which offer only a portion of the functionality of an IDE, something which shouldn't be news to you). Vim has its place but not in the IDE world (and I'm saying this as a Vim/VSCode user).

@0x5d0 sidenote: N++ has macros. Not sure if they're as powerfull as vim as I have no experience with vim macros, but I had scripted some data manipulation tasks (replace, reformat, delete lines) in N++ and they worked just fine.

It's not code quality that's at fault. Disciplined programmers always existed.

It's that programming as a profession became so massively widespread that so many thousands of tools and languages popped up, each a new layer of abstraction.

The real reason languages like JavaScript are so messy today isn't because of design but because of politics and the lack of a single powerful authority deciding what's right or wrong, unlike say languages like Java where one company has full control (even that is getting fucked by kotlin)

The more layers of corporate you have, the more abstraction gets pushed into the code community. Code is slower today not because of programmers but because of lack of good community design structure.

When it actually comes to making mission critical code, like say google maps or something the military builds, where one team has absolute design control, the speed of programs today is fucking light years ahead of the old days.

What you clearly miss the time it takes to develop something in Qt over Electron. By the time an electron app is designed, implemented and tested a standard C++ team is still arguing about how to configure the buildchain.
These thousands levels of abstractions that you hate so much have a purpose, it is that a UI Developer doesnt have to deal with shit like memory management, and can actually deliver an app or a feature in a reasonable time frame.
The faster the language the longer the devtime, general rule of thumb.

@EdoPhoenix THAT

But I would agree that electron is pretty shitty.

Mostly we are trading dev time vs performances / possibilities.

Personally If I need ever again to build a standalone soft, I would go with C#/WPF (Not UWP).

Simple because I know it well, it's supported, it uses system setting for themes and i'm good with C#.

But mostly, my first reflex is : Can I do it web based ? So I can update it my self and not rely on users. And also HTML integrators are cheap.

@EdoPhoenix I can agree on a somewhat faster delivery time. Could still argue though, I'm a first-hand witness of the modern JS ecosystem's complexity and have seen lots of completely redundant rituals surrounding the apps. People often plan on doing a larger-scale application, which leads to their projects having a lot of bloat they would've avoided with a better planning.

The problem is, large companies do it. Look at MS Teams or VSCode, for instance. Look at Slack. Look at Discord It's not like they're short on resources to make a faster and lighter version for the app in question. It's just they don't ever come around to do it while the initial trajectory likely treated an Electron thing as an MVP that was to be replaced once the hypothesis is tested (Slack/Discord for sure belong to this category). Mind you, there's an alternative implementation of Discord in GTK, and it's completely open-source, made by eight devs or so.

@0x5d0 I don't know about slack but with discord and VSCode the choice fell on electron mainly because they wanted a platform independent, consistent renderer. The big nightmare of crossplatform UI is that even if you get it to look good on windows, apple and linux are a different story. Apple has their UI philosophy, and without implementing your own renderer(or use chromiums) you are stuck with that cancer. And supporting native linux is the best way to shoot yourself in the foot. They are at best 5% of your users, and have 99% of the graphics bugs. Mostly because Linux implementations for graphics are a steaming pile of shit or just dont exist. This is especially true for videogames, just the performance difference between some titles on Linux vs Windows is abhorrent.

Don't use electron. Electron is fucking cancer.

Use Nw.js.

It's light, portable, and runs respectably.

Your run time for an Nwjs app is like sub 20 mb.

Thats not bad considering you get

1. the whole of css

2. including animations

3. any framework or js library you want

4. easy backend/desktop access

5. not having to fucking deal with npm/package management fuckery and babylonian dependency hellscapes written in cuneiform and made of fragile glass.

@0x5d0 I agree with all even the IDE to some extent. I use idea ideas because they make life easier but they could be lighter.

I've seen crazy shit that could easily optimized but you have to except that we don't have to over do it to a point that when you have a python app you gonna rewrite it in assembly just so you can do more optimal. It's fast enough if you write it correctly in python

@hjk101 I have nothing against using technologies for tasks they were designed to solve, don't get me wrong. It's just that tools often get misused, and it goes completely under the radar, creating atrocities marketed as finished products.