221–230 of 342 posts
Earlier quoted context omitted.
macOS just notified me that one tab in Safari was using so much memory it was threatening performance of my laptop. The website in question? https://idioms.thefreedictionary.com/ It was close to 2Gb RAM usage. Bunch of ad-tracking stuff, I assume, as Firefox and its related processes seem to be using less than 1250mb with 6 tabs open, including the site mentioned in 2 tabs. My firefox has uBlock origin installed. See…
Last week my bandwidth grounded to a halt which is usually the result of someone uploading on my network. I went to my girlfriend's computer to see if she was syncing with Dropbox or something. Nope. She quit all of her applications just to be sure. Except for a single browser tab opened to a recipe for pita bread. Yep, turned out that a recipe for pita bread was saturating our router because what looked to be buggy…
Everything has a context. If your site has: - minimal functionality - rarely if ever changes - is maintained by a very small group (Hacker News) ...then something like the example linked is perfect. Most web app developers don't live in this world. The more common situation is: - large and/or transient teams - large quantity of inter-dependent features - constant changes ...which means that the thing you need to opti…
If that's true, then the app will likely have what I call a "programmer's interface" (which is especially common in most enterprise web apps I encounter). Those apps might be solid from a code perspective, but don't tend to be very user friendly.
I tend to think that modern web apps are more about dealing with the complexities of balancing functionality with ease of use to the end user while still dealing with the complexities of large product teams, which include but are not limited to designers, UX experts and developers.
Earlier quoted context omitted.
That's true if you're talking about using React, Vue, etc. but do you really think ES5 JavaScript is more likely to be supported in the future than ES6?
I'm talking about NPM modules and the build toolchain (which consists of even more NPM modules). This stuff goes stale very quickly (at the 10-year scale). It's good for a project that is kept continuously alive (i.e. when there is a team of developers that is continuously making changes to the project), but not when the project sits on a shelf for 10 years and then needs to be modified.
I don't understand why people are dissing this. It does what it's designed to do, and fills a specific need for one website. It's not there as a teaching aid, nor is it meant to be shared for other people to use elsewhere. Not everything has to be gold-standard code full of perfect variable names, extensive comments and good whitespacing. If you have a day job that isn't primarily writing code, and/or you are likely…
> As long as the code works, anything else is just gravy. Nonsense. Maintainability almost always matters. As the adage goes: code shouldn't merely work, it should clearly work. > If you were to peel back the layers on all the major websites out there, I'm sure you'd find less than stellar code everywhere. Indeed, but Sturgeon's Law shouldn't make us feel better.
The last three large corporations I worked for never cared about maintainability because the application or portal would only be in use for maybe a year or 18 months before a complete rewrite or total redesign.
All of the recent projects I've been on take the same approach. Get it stood up, make it look pretty and release it. Because agile development makes business owners believe it only takes a few days to build Rome now, maintainability is never a consideration on any of the projects I've been on. Even senior devs are saying, "It's pretty hacky to get this to work, but it works" is a common troupe on our teams. I agree maintainability should be important, but on the agile projects I've been on, nobody cares about it.
To some degree I think executives do it on purpose so they can create more work for themselves in the future. They can pick it apart, ask for a bigger budget, hire more devs and use some shiny new technology to build it over again. Rinse, repeat.
Earlier quoted context omitted.
I'm talking about NPM modules and the build toolchain (which consists of even more NPM modules). This stuff goes stale very quickly (at the 10-year scale). It's good for a project that is kept continuously alive (i.e. when there is a team of developers that is continuously making changes to the project), but not when the project sits on a shelf for 10 years and then needs to be modified.
Right, my point was that this is a subset of modern approaches.
The authors is quite lazy or cannot type fast enough, so he has to create all those cryptic abbreviations: `rks` for `ranks`, `unv` for `unvote`, etc. Which makes it really hard to read. But it's especially the inconsistent use of camelcase in function names than makes me think it's pretty amateurish.
There are some polarized opinions in this thread. Someone wrote That might be one of the most readable pieces of code that I've ever read. Apparently it improves readability immensely to rename 'forEach' to 'aeach'. To be honest the code is not very readable, but it is very simple and self contained. It would be very easy to dive into to fix a bug because there are no external dependencies or frameworks you have to u…
Perhaps this why HN still uses tables for presentation - nobody dares to change it? There's also simply no reason to change it, it works.