4 ms·

Hi, undergrad here. That is to say, I’m not anything close to an expert in web design, but just in the course of making a simple static website to show recruite

Hi, undergrad here. That is to say, I’m not anything close to an expert in web design, but just in the course of making a simple static website to show recruiters I realized a lot of lessons like these about how modern HTML/CSS/JS can really handle anything you throw at it without having to worry about frameworks or precompilers. Sure, Bootstrap and SASS helped get a prototype up fast, but I feel like that gain in productivity was wasted once I had to fight the framework for the fine details, and just writing what I wanted in vanilla-land ended up writing out the frameworks as a byproduct. Is this a common pattern in industry as well?

zdragnar 7y ago
JS, no. A hand rolled framework is going to be a hindrance the more feature-ful your site becomes. OTOH, css frameworks go the other way. The more you have to do, the more apparent that bootstrap etc. get in your way, largely because css isn't a "complete" language. I know some few who swear by them, but the majority of people I know who did html/css exclusively for years feel they can write by hand anything they would want from bootstrap in less time than they would waste in fighting things like selector specificity and other inflexible choices. YMMV of course, and you can pry postcss + preset-env + mixins from my cold, dead hands.
mjlangiii 7y ago
It is a bit of catch-22 IMHO, for some. If you're very experienced it is just as easy to roll your own (although others may not onboard as quickly compared to well known libraries). If you're not very experienced then if you try to roll your own it may wind up being a mess. I'm in the middle and once I understand a library well I know its limitations and use its components as they were intended where I won't have to customize them too much, and roll my own components for the rest. This largely sidesteps the issues I used to have of wrestling with UI frameworks. I hope that helps.
- ethhics 7y ago
  Certainly! I wanted to hear some viewpoints about full vanilla vs framework-based development, and your view of grokking the tools and implementing what it doesn’t cover is a great one to consider.
linuxftw 7y ago
> Is this a common pattern in industry as well? It is on the server-side (php, python). Sophisticated apps can easily outgrow a particular framework. Though, I think php frameworks are pretty mature these days and this is less of an issue there than it once was.
hombre_fatal 7y ago
At the same time, you have to ask yourself if your customizations are so important that it's worth maintaining your own CSS. There are obvious trade-offs there. CSS files often incur irreversible complexity without someone dedicated to fight it. Forgoing a CSS framework completely has its own large costs like eternal vigilance, organization, and documenting some sort of strategy for other developers to follow (since they can't just read a framework's docs anymore).
btmiller 7y ago
It’s going to depend. If you’re going into the web front end field, you’ll be able to make that determination yourself. For me, as an SRE with higher priorities, you can pry Bootstrap from my cold, lifeless fingers :) I have zero interest in keeping up with latest and greatest in CSS developments; like you said, Bootstrap gets you something up and running fast without much fuss. It’s good enough and it allows me to focus on other important areas.
- ethhics 7y ago
  Thanks, I’m actually going into the semiconductor industry :D I figured that it would depend quite a bit about the timeframe and scale of the project you’re working on, which is why I was curious for some wider experiences and opinions
BigJono 7y ago
The most common pattern in industry is to slather everything with libraries until you end up doing 10x the amount of work you needed to do. An actual 'good' approach is to mostly utilise vanilla tooling like you suggest, but there are some exceptions, you can't be absolutist about it. I think for a decently sized web application, React (and only React, not all the cruft people usually include with it) will save you a lot of effort, and not using it would be a mistake. You could go with something like Vue instead but React does a much better job at abstracting away the huge amount of utility it provides. It has a smaller API surface by an order of magnitude. I think a good thought exercise is to think about what a 'perfect' implementation of the library you're thinking of using would look like for your exact use case, and compare it to using the actual library. Even if my use case doesn't include any performance requirements, I don't really think my implementation of a React-style solution would have less than 1k-2k LoC, and the implementation wouldn't be very simple. Contrast that to something like Redux which could be roughly implemented in ~20-100 LoC for most use cases and is conceptually very simple.

zdragnar 7y ago

JS, no. A hand rolled framework is going to be a hindrance the more feature-ful your site becomes. OTOH, css frameworks go the other way. The more you have to do, the more apparent that bootstrap etc. get in your way, largely because css isn't a "complete" language. I know some few who swear by them, but the majority of people I know who did html/css exclusively for years feel they can write by hand anything they would want from bootstrap in less time than they would waste in fighting things like selector specificity and other inflexible choices. YMMV of course, and you can pry postcss + preset-env + mixins from my cold, dead hands.

mjlangiii 7y ago

It is a bit of catch-22 IMHO, for some. If you're very experienced it is just as easy to roll your own (although others may not onboard as quickly compared to well known libraries). If you're not very experienced then if you try to roll your own it may wind up being a mess. I'm in the middle and once I understand a library well I know its limitations and use its components as they were intended where I won't have to customize them too much, and roll my own components for the rest. This largely sidesteps the issues I used to have of wrestling with UI frameworks. I hope that helps.

ethhics 7y ago
Certainly! I wanted to hear some viewpoints about full vanilla vs framework-based development, and your view of grokking the tools and implementing what it doesn’t cover is a great one to consider.

linuxftw 7y ago

> Is this a common pattern in industry as well? It is on the server-side (php, python). Sophisticated apps can easily outgrow a particular framework. Though, I think php frameworks are pretty mature these days and this is less of an issue there than it once was.

hombre_fatal 7y ago

At the same time, you have to ask yourself if your customizations are so important that it's worth maintaining your own CSS. There are obvious trade-offs there. CSS files often incur irreversible complexity without someone dedicated to fight it. Forgoing a CSS framework completely has its own large costs like eternal vigilance, organization, and documenting some sort of strategy for other developers to follow (since they can't just read a framework's docs anymore).

btmiller 7y ago

It’s going to depend. If you’re going into the web front end field, you’ll be able to make that determination yourself. For me, as an SRE with higher priorities, you can pry Bootstrap from my cold, lifeless fingers :) I have zero interest in keeping up with latest and greatest in CSS developments; like you said, Bootstrap gets you something up and running fast without much fuss. It’s good enough and it allows me to focus on other important areas.

ethhics 7y ago
Thanks, I’m actually going into the semiconductor industry :D I figured that it would depend quite a bit about the timeframe and scale of the project you’re working on, which is why I was curious for some wider experiences and opinions

BigJono 7y ago

The most common pattern in industry is to slather everything with libraries until you end up doing 10x the amount of work you needed to do. An actual 'good' approach is to mostly utilise vanilla tooling like you suggest, but there are some exceptions, you can't be absolutist about it. I think for a decently sized web application, React (and only React, not all the cruft people usually include with it) will save you a lot of effort, and not using it would be a mistake. You could go with something like Vue instead but React does a much better job at abstracting away the huge amount of utility it provides. It has a smaller API surface by an order of magnitude. I think a good thought exercise is to think about what a 'perfect' implementation of the library you're thinking of using would look like for your exact use case, and compare it to using the actual library. Even if my use case doesn't include any performance requirements, I don't really think my implementation of a React-style solution would have less than 1k-2k LoC, and the implementation wouldn't be very simple. Contrast that to something like Redux which could be roughly implemented in ~20-100 LoC for most use cases and is conceptually very simple.