| ▲ | nekooooo 8 hours ago |
| modern engineering is launching an electron to-do list app that uses 2gb of ram. |
|
| ▲ | high_na_euv 7 hours ago | parent | next [-] |
| Which, at least works relibly across all platforms and devices unlike desktop frameworks? People wouldnt use electron is they had good alternative |
| |
| ▲ | bigstrat2003 10 minutes ago | parent | next [-] | | Literally anything is a good alternative to electron. One should prioritize the quality of the product, and use of electron gives the lowest quality product. | |
| ▲ | quietbritishjim 6 hours ago | parent | prev | next [-] | | Flutter / Dart? It's compiled ahead of time and doesn't use an embedded browser so I'd expect it to be a lot lighter, though I haven't measured. But the general lack of really cross-platform (desktop + mobile + maybe web) ecosystems is just as much as sign that devs consider multi-gigabyte Electron apps "good enough" as the apps themselves. | | |
| ▲ | pixl97 2 hours ago | parent [-] | | >at devs consider multi-gigabyte Electron apps "good enough" as the apps themselves. This kind of misses out on a hierarchy of devs here and the amount of work to make it happen. Electron took a large chunk from a multi-billion dollar endeavor to use to make all this work. Electron only worked because Chrome was there. Chrome worked because Google already had unlimited money from advertising, and getting advertising on every device possible was their goal. Devs might want light apps everywhere, but seemingly none are going to dedicate the rest of their life and money to make it work. | | |
| ▲ | quietbritishjim an hour ago | parent [-] | | True, not every dev has the power of a multi-billion dollar company behind them. But a few do. My point was, if enough people really considered this a big deal then at least one huge tech company might have invested in a solution that provides a lighter weight solution that's truely multiplatform (desktop and mobile). I don't have much visibility on how decisions are made to maintain massive open-source infrastructure projects, and no doubt there are significant business case inputs to them, but they must be at least partially technical. So, as I see it, the lack of such things give insight that even developers don't prioritise them. As I mentioned, Flutter is almost there and maybe its lack of uptake on desktop is just enough to show that there really isn't demand (though I expect the main reason is its use of the Dart programming language, which is very nice but quite niche). | | |
| ▲ | pixl97 28 minutes ago | parent [-] | | >but they must be at least partially technical. Having sat in many a meeting, partially yes, but these things are massively expensive. There is an equation, How much would it cost us to write a replacement that covers what we need versus how much does it cost us to use what exists that isn't efficient. And this is where you miss the biggest part of the problem. It's the end users that bear the biggest part of the costs. Yes, there is an internal cost for their own developers, but that is comparatively small to the costs of their paychecks. The next comes to management of the lightweight solution over time. If it's owned by a company at the end of the day companies are rarely interested in lightweight, they are interested in making the most money and quite often that means adding more and more features to accomplish lock-in. Open source is more likely to keep a project remaining light, but to do that it's quite often by not accepting bulky features that would make companies more money. So you see where the catch-22 situation starts to arise from. |
|
|
| |
| ▲ | steve1977 4 hours ago | parent | prev | next [-] | | Reliable as in "exposes the same bug across all platforms"? | |
| ▲ | lynx97 5 hours ago | parent | prev | next [-] | | If you are willing to ignore accessibility, your statement is right. | |
| ▲ | iwisjwudjqjdw an hour ago | parent | prev [-] | | [dead] |
|
|
| ▲ | aix1 7 hours ago | parent | prev | next [-] |
| What I'm seeing more and more of is junior folks blindly taking LLM-generated code and including it into their systems, without even trying to understand it or think critically about what it does and where it might break. Maybe I am living in the past, but it does make me think that they might be depriving themselves of an opportunity to develop key skills. |
| |
| ▲ | pixl97 2 hours ago | parent [-] | | >without even trying to understand it or think critically about what it does and where it might break. You are living in a past, but one much farther back than you expect. People were copying code from SO since it became popular. People are including node modules blindly before AI. Most developers suck, terribly. Maybe being on HN is a type of filter that shows you're just a little bit better than the average, but the number of developers on HN is small versus the total number of developers. Edit: I was copying code out of magazines to get games running without understanding anything about it when I was young. | | |
| ▲ | aix1 an hour ago | parent [-] | | First of all, that's a very different sort of thing compared to blindly taking reams of code from an LLM. The amounts of code in a given SO answer or a magazine article are tiny and the code has undergone review of one sort or another. Similarly, if I take QR decomposition code from Numerical Recipes, that's quite likely to be better quality than what I -- or most folks -- can code up in a comparable amount of time. It's also an opportunity to learn by studying the code and the method. Secondly, I am not talking about some abstract SWEs in a vacuum. This is happening to real people I work with, whom I know to be very capable. The lure of switching off the brain and just clicking "Accept" to some LLM suggestion seems too strong to resist. :( | | |
| ▲ | pixl97 an hour ago | parent [-] | | Really what you're saying is it is an issue of quantity. > if I take QR decomposition code from Numerical Recipes, I'm going to assume the vast majority of code written does not look anything like this, but is dumb little chunks of glue for other important chunks, that are quite often imported from other libraries. As someone that is not a SWE looking from the outside, I think there is a disconnect between what a SWE is told they are getting paid for and what a SWE is actually getting paid for by (many/most) businesses. You are under the assumption you are getting paid for writing code. But for the vast majority of business that is just the icky bits getting ground up in the sausage factory that nobody wants to know about. Management above you only cares about what gets wrapped in casings and is ready to sell to the customer (either internal or external). They do not care if the product is technically good as long as they can sell it. For each individual person in the company becoming a better programmer is hard to measure and rarely rewarded by the company they work for. Turning out tons of lines of code and applications that have at least some semblance of working is far more likely to get you a pay raise. |
|
|
|
|
| ▲ | serial_dev 7 hours ago | parent | prev [-] |
| Then they justify it because they vibe-coded a proof of concept in Tauri, and it was even worse. |
