231–240 of 342 posts
Earlier quoted context omitted.
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…
How was the pita?
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.
Earlier quoted context omitted.
This 100x times. There is very little code there . Any effort in trying to bring it up to modern webdev standards would likely make the code expand significantly, and that's not even counting the complexity of the deployment pipeline. This here, it's just 150 lines of plain code. It's not hard to work with something like this.
I'm not saying a rewrite is necessary at all, but refactoring this code to use more modern standards would NOT increase the line count at all, my guess it it might cut it by 15%+ in total size if you leveraged the beautiful builtin functions. Compare these: function addClass (el, cl) { if (el) { var a = el.className.split(' '); if (!afind(cl, a)) { a.unshift(cl); el.className = a.join(' ')}} } Could turn into somethi…
And won't work on IE. Not just because of el.classList, but also because of the arrow notation. So by doing this change, you either have to ditch one of still used browsers, or introduce a stupidly complex transpilation chain into the mix.
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.
This style is very similar to one which is used by expert C programmers, it seems that most people that write like this have had experience writing parsers and compilers too. It's not their fault that most people don't just think purely in terms of function composition :P
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…
In a small, simple, established site, those needs don't change often, so the code doesn't change often, and you can focus more on performance than maintainability, as well as spend your efforts on non-coding tasks.
In a startup when you are finding your market and seeking product/market fit, and you've got investors demanding speedy delivery of a product to customers, the attempted solution is often a large team with fast and numerous code changes. And then you do have to optimize for the devs, because even though the final goal is customer satisfaction, devs need to perform efficiently to hit that goal.
The needs of the codebase still tie back to the needs of the business. One answer does not fit all.
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…
>> Modern web apps are less about being performant and minimal, and more about dealing with the complexities of large software teams 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…
I can't be the only person who finds browser default behavior more intuitive and usable in general.
Why does "UX" so often mean mouse-heavy and always favor the beginner over the power-user.
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…
From the top down (strategic), and from the bottom up (tactical).
Depending on your perspective, you will likely fixate on different things.
If you're starting from the bottom, you'll probably be more interested in the coding choices made by the developer.
If you're coming from the top, you'll probably look at the goals of the site and whether the code met them, and then consider other details like optimization and cleanliness to be secondary ('gravy').
When I was in biz-school in the 90s, we used to spend a lot of time talking about effectiveness (the end result does what it needs to do) and efficiency (the end result does what it needs to do and is optimized for -insert criteria here-).
Ideally, you get to be both effective and efficient. If, however, you can only be one, it's better to be effective.