undefined | Better HN

0 pointsrev_bird10y ago0 comments

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?

0 comments

gjolund10y 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/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".

rev_birdOP10y ago

This is really interesting, thanks for responding. It seems, though, like the vast majority of these problems aren't coming from the necessary evils brought about by outdated technologies -- it just seems like inexperienced (or just...bad) coders trying to shove stuff out the door on the cheap. If the people who made the original project had been "using" React, I'd imagine you'd just be dealing with the busted CSS and mangled JSX everywhere.

This raises an interest point that I think I was missing before -- "imposing structure on your developers via solid frameworks and tools." The idea that even if you don't need the functionality of a particular framework, a framework's prescriptive way of doing things might reduce enough of the variance in styles to make a big project more coherent.

gjolund10y ago

That's just the thing.

Having a framework in place minimizes the impact of those "bad programmers" to just a single ui component, or api route, or database migration.

Not having a framework in place means that that intern or contractor from india can now introduce bugs that impact the entire system and are nearly impossible to track down.

I feel like it shouldn't be such a hard sell to get software engineers to admit that structure and consistency are good things.

johnny2210y ago

"imposing structure on your developers via solid frameworks and tools." is exactly why i use frameworks.

kup010y ago

We initially may have seemed to have different ideas of "simplicity", because I certainly agree that if using a framework works for a site, and allows you to re-use code to avoid extra lines (like the extra CSS, jQuery, etc. you mention) then that is the best way to go.

When I said simple, maybe I meant "efficient" instead. I just see a lot of misuse of frameworks where all of the code is thrown in and then barely customized to make it work, and all the extra unused cruft is left in. Basically pages are loading a bunch of stuff that is never actually used...

So I think maybe we were speaking past each other a bit, because I generally agree with you.

The initial post at first seemed a bit hostile, but some of that I think we're inferring- because we're reading our own tone into the text. Also, as you said, it's something you constantly deal with, so I'm sure it's a big point of frustration for you.

When frameworks work to allow you to clean up a codebase or prevent it from becoming the mess you describe, then they definitely make sense. When they cause bloat for no good reason- that's when I have a problem with them.

I guess it all comes down to developer use/misuse of them, not the frameworks themselves, in most cases.

j / k navigate · click thread line to collapse

0 comments

gjolund10y 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 )

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/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.

rev_birdOP10y ago

gjolund10y ago

That's just the thing.

Having a framework in place minimizes the impact of those "bad programmers" to just a single ui component, or api route, or database migration.

Not having a framework in place means that that intern or contractor from india can now introduce bugs that impact the entire system and are nearly impossible to track down.

I feel like it shouldn't be such a hard sell to get software engineers to admit that structure and consistency are good things.

johnny2210y ago

"imposing structure on your developers via solid frameworks and tools." is exactly why i use frameworks.

kup010y ago

So I think maybe we were speaking past each other a bit, because I generally agree with you.

I guess it all comes down to developer use/misuse of them, not the frameworks themselves, in most cases.

j / k navigate · click thread line to collapse