4 ms·

It's annoyingly bad at this point. You know it's gotten bad whenever new frameworks are coming out where being "minimal" is a feature. Page loads are very larg

by kup0 11y ago

It's annoyingly bad at this point. You know it's gotten bad whenever new frameworks are coming out where being "minimal" is a feature. Page loads are very large on some sites now, where they don't have to be. Though, advertising can be blamed for a lot of that. There's just a lot of extra cruft out there now, without much added to the user experience, in fact, it often detracts from it. What happened to using only what is necessary? Why throw so much unused stuff behind a site, and especially, why load anything you're not using? Why complicate things? Maybe I'm nostalgic for static pages or something, but I miss the days where things were simple in terms of page loads and efficient design, and I think a technologically-advanced but focused (avoiding excessiveness) approach is best going forward. This philosophical approach is one reason I like the Hacker News site itself. It accomplishes its task well, and is almost solely text and minimal css. It's running on some stuff built underneath (as dynamic pages require), but it seems pretty minimal in general. It needs nothing extra.

gjolund 11y ago
Websites are becoming more complex. Deal with it. I'm sure people said the same thing about the gutenburg press vs locking a bunch of monks in a room for 20 years. That being said, if you don't understand the tech, or the tooling that implements it, don't use it. Keep doing things the hard way, I really don't care. In a few years we will be writing config files for machine learning algorithms to stitch together a ui based on requirements doc, or an api specification. You can already see this within AWS API gateway and lambda functions, and a lot of the R&D being done around procedurally generated ui's. The developers that fail to adapt will be left building sites using legacy tooling for shit clients who don't know better. Or move into management where they can impose their archaic views on their subordinates who do know better. Either way, no one is forcing you to write code you don't understand, that is 100% your fault. I look forward to the day that I can automate away the need for sub par developers polluting codebases with their versions of "simplicity". I am currently re-writing a 100k line js app for a fortune 500 company, the initial contractors were trying to keep things "simple" by using 10 year old tech. They all got fired 2 days after my proof of concept demo.
- rev_bird 11y ago
  I was with you initially, but this seems hostile in a way that's honestly kind of confusing. The argument, as I understand it, isn't something like "websites are too complex now," it's that "web-app programming is becoming more complex without corresponding returns on functionality or UX." Your example, though it's buried under a bunch of stuff calling people dumbasses, makes an interesting point: You're right, there isn't anything simple about 100,000 lines of code in ANY language, even if it's 100,000 necessary lines. What were they trying to do that was so easy to replace? What kind of JS was knocking around in 2005 -- is it all display stuff and wonky jQuery?
  - gjolund 11y ago
    If I seemed hostile, it is because I am dealing with this exact topic on almost a per contract basis, and it is becoming exhausting. However I don't recall calling anyone a dumbass. Here are some ( sanitized ) examples from my current project that exemplify the danger of allowing this line of thinking among your contractors: 1. Completely unmanaged client dependencies on a per page basis ( negligible code, infinite heartache ) 2. Template files that do not reuse code due to laziness or differences in markup style ( 20k+ extra lines of code ) 3. CSS files crafted on a per page basis, again little code reuse due to developer style and competence ( 20k+ extra lines of code, huge download size, difficult cacheing requirements ) 4. Confusing and undocumented deployment procedures ( I had to completely rebuild the infrastructure from the ground up ) 5. Each and every page had a its own js file, with its own global exports, dependencies, and code style. Most were over 1000 lines of untested jQuery Stackoverflow answers. 65 unique pages, sharing almost no code. 6 My favorite, a grunt task that searched the code for 'some_var + other_var' and replaced it with a string literal "https://my-dynamically-generated-cdn-fingerprint.cdn.com/resouce/" https://my-dynamically-generated-cdn-fingerprint.cdn.com/res... 7. Superflous build tasks and bugs due to inconsistent project structure. Some people like /dist others /builds etc. The list goes on, I'm finding more stuff every day. This is a well funded project, 1 year into development. Just implementing react, gulp, and sass allowed me to remove 60k lines of code over 2 months. The app still works in a request / response method, haven't gotten to that yet. The backend is still a tangle of coffeescript. This is the risk you run by not imposing structure on your developers via solid frameworks and tools. If you can't pick the best tool for the job, hire someone who can. Otherwise you'll end up hiring him anyways to fix your broken 20 million dollar "unicorn".

by kup0 11y ago

gjolund 11y ago

Websites are becoming more complex. Deal with it. I'm sure people said the same thing about the gutenburg press vs locking a bunch of monks in a room for 20 years. That being said, if you don't understand the tech, or the tooling that implements it, don't use it. Keep doing things the hard way, I really don't care. In a few years we will be writing config files for machine learning algorithms to stitch together a ui based on requirements doc, or an api specification. You can already see this within AWS API gateway and lambda functions, and a lot of the R&D being done around procedurally generated ui's. The developers that fail to adapt will be left building sites using legacy tooling for shit clients who don't know better. Or move into management where they can impose their archaic views on their subordinates who do know better. Either way, no one is forcing you to write code you don't understand, that is 100% your fault. I look forward to the day that I can automate away the need for sub par developers polluting codebases with their versions of "simplicity". I am currently re-writing a 100k line js app for a fortune 500 company, the initial contractors were trying to keep things "simple" by using 10 year old tech. They all got fired 2 days after my proof of concept demo.

rev_bird 11y ago
I was with you initially, but this seems hostile in a way that's honestly kind of confusing. The argument, as I understand it, isn't something like "websites are too complex now," it's that "web-app programming is becoming more complex without corresponding returns on functionality or UX." Your example, though it's buried under a bunch of stuff calling people dumbasses, makes an interesting point: You're right, there isn't anything simple about 100,000 lines of code in ANY language, even if it's 100,000 necessary lines. What were they trying to do that was so easy to replace? What kind of JS was knocking around in 2005 -- is it all display stuff and wonky jQuery?
- gjolund 11y ago
  If I seemed hostile, it is because I am dealing with this exact topic on almost a per contract basis, and it is becoming exhausting. However I don't recall calling anyone a dumbass. Here are some ( sanitized ) examples from my current project that exemplify the danger of allowing this line of thinking among your contractors: 1. Completely unmanaged client dependencies on a per page basis ( negligible code, infinite heartache ) 2. Template files that do not reuse code due to laziness or differences in markup style ( 20k+ extra lines of code ) 3. CSS files crafted on a per page basis, again little code reuse due to developer style and competence ( 20k+ extra lines of code, huge download size, difficult cacheing requirements ) 4. Confusing and undocumented deployment procedures ( I had to completely rebuild the infrastructure from the ground up ) 5. Each and every page had a its own js file, with its own global exports, dependencies, and code style. Most were over 1000 lines of untested jQuery Stackoverflow answers. 65 unique pages, sharing almost no code. 6 My favorite, a grunt task that searched the code for 'some_var + other_var' and replaced it with a string literal "https://my-dynamically-generated-cdn-fingerprint.cdn.com/resouce/" https://my-dynamically-generated-cdn-fingerprint.cdn.com/res... 7. Superflous build tasks and bugs due to inconsistent project structure. Some people like /dist others /builds etc. The list goes on, I'm finding more stuff every day. This is a well funded project, 1 year into development. Just implementing react, gulp, and sass allowed me to remove 60k lines of code over 2 months. The app still works in a request / response method, haven't gotten to that yet. The backend is still a tangle of coffeescript. This is the risk you run by not imposing structure on your developers via solid frameworks and tools. If you can't pick the best tool for the job, hire someone who can. Otherwise you'll end up hiring him anyways to fix your broken 20 million dollar "unicorn".