3 ms·

This is surprisingly not true, have you tried ? When you start from scratch you realize you have a tiny minuscule surface and securing that very small hole is m

by xwolfi 4y ago

This is surprisingly not true, have you tried ? When you start from scratch you realize you have a tiny minuscule surface and securing that very small hole is much easier than say... fixing the log4j 20th level transitive dependency of your giant Spring Framework that was secretly able to interpret random input from logs or someth. Especially if all you wanted was to show a quick html output. It's incredibly common to see giant dynamic web stuff used for tiny static output that could have done without. I've done both in large volume websites and I find now that using as little "framework" as possible and a limited number of "libraries" works better in terms of cost, bugs, dev attrition, business desire implementation and user speed of render. Picture a giant mess of node dependencies surrounding a central giant quirky framework like VueJS. 5 years of dev, all devs left. You need to maintain that, is that going to be easy ? Wasn't for me.

claytongulick 4y ago
I'm living this right now. It's why when I have greenfield I do vanilla web components, with a little lit-html sprinkled in for fast rendering. I've seen so many developers complain about how complex vanilla web components are, and they'll turn around and do React / Vue / Angular and Redux or (shudder) rxjs, etc... I just don't get it. Like, if you need reactivity... Stick a render call into the setter of a plain old property. If you don't, use a variable. The whole computed() thing with Vue makes things so complex... I have to deal with a huge rabbit hole of that stuff all the time. I think to myself... I could just use a property, and I wouldn't need a whole painful build step, type definitions, framework version specific DSLs, massive complex source maps that don't work, Rube Goldberg state machines, crazy pseudo DOM elements that aren't really DOM elements, unless they are, or a ref to something magic that might end up being a DOM element someday, obscure dependency injection cruft that's done way better by just using dynamic imports... I remember when I couldn't wait for Proxy to be widely supported by browsers. Now I'd do anything to be able to shove that toothpaste back into the tube. I don't know. I don't see any of this providing any value. I feel like the emperor has no clothes, but everyone else thinks he's wearing Armani.
- prox 4y ago
  I am in front end webdev, and a lot of time I have had design colleagues that came up with crazy paid solutions for something as simple as a pop up. When I overheard and mentioned I could implement that in 2 hours tops it was a bit of a no brainer. The pure design folks often don’t know the tools or what’s possible. To this day I just do mysql/php/js and simple ajax calls for a lot of solutions. Most clients are in the 100k-500k of hits and it works fine.
ratww 4y ago
Yep, same experience. A large "ecosystem" is touted as a great advantage of some frameworks, but the reality is that it's mostly unmaintained low-quality libraries that could be replaced by a few lines of easier to understand code. "The Ecosystem" is about quantity over quality, all the way down. And when those unmaintained libraries break, you're also in the hook for fixing them, but it takes way more time and coordination than fixing it if it were your own code.

by xwolfi 4y ago

claytongulick 4y ago

I'm living this right now. It's why when I have greenfield I do vanilla web components, with a little lit-html sprinkled in for fast rendering. I've seen so many developers complain about how complex vanilla web components are, and they'll turn around and do React / Vue / Angular and Redux or (shudder) rxjs, etc... I just don't get it. Like, if you need reactivity... Stick a render call into the setter of a plain old property. If you don't, use a variable. The whole computed() thing with Vue makes things so complex... I have to deal with a huge rabbit hole of that stuff all the time. I think to myself... I could just use a property, and I wouldn't need a whole painful build step, type definitions, framework version specific DSLs, massive complex source maps that don't work, Rube Goldberg state machines, crazy pseudo DOM elements that aren't really DOM elements, unless they are, or a ref to something magic that might end up being a DOM element someday, obscure dependency injection cruft that's done way better by just using dynamic imports... I remember when I couldn't wait for Proxy to be widely supported by browsers. Now I'd do anything to be able to shove that toothpaste back into the tube. I don't know. I don't see any of this providing any value. I feel like the emperor has no clothes, but everyone else thinks he's wearing Armani.

prox 4y ago
I am in front end webdev, and a lot of time I have had design colleagues that came up with crazy paid solutions for something as simple as a pop up. When I overheard and mentioned I could implement that in 2 hours tops it was a bit of a no brainer. The pure design folks often don’t know the tools or what’s possible. To this day I just do mysql/php/js and simple ajax calls for a lot of solutions. Most clients are in the 100k-500k of hits and it works fine.

ratww 4y ago

Yep, same experience. A large "ecosystem" is touted as a great advantage of some frameworks, but the reality is that it's mostly unmaintained low-quality libraries that could be replaced by a few lines of easier to understand code. "The Ecosystem" is about quantity over quality, all the way down. And when those unmaintained libraries break, you're also in the hook for fixing them, but it takes way more time and coordination than fixing it if it were your own code.