Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Thank You Bootstrap 1

kylerego.github.io

Post reply on HN
Print view View original

11–20 of 65 posts

Re: Thank You Bootstrap 1

#11

Post by gedy »

danpalmer wrote: post #7

Something that I've often wished, as a primarily backend focused engineer, often without frontend support, is for designers or perhaps design engineers, to pretty much build Bootstrap themes. That would let me code to the Bootstrap docs (which are pretty good), while allowing us to brand or customise whatever we're working on. I've seen even contract designers push back on this idea, suggesting that doing such a thin…

> What am I missing?

You're not missing anything, companies like mine have done just this.

We supported a messy situation of 7 webapps using different technologies looking 7 different ways. Once we got them to use Bootstrap, was a cinch to consolidate to a single company brand.

The "big reskin" UX was gearing up for was as simple as a new theme, and was done without any drama. They were almost disappointed it was so easy, ha.

I like Tailwind, but it's a rotten fit for reskinning (not just changing font or colors). I'd much rather have a single .card class, vs "p-3 border-1 shadow-sm rounded-2" or whatever. Not all of us have have the luxury of a single modern app all using the same React components.

Re: Thank You Bootstrap 1

#12

Post by BillSaysThis »

danpalmer wrote: post #7

Something that I've often wished, as a primarily backend focused engineer, often without frontend support, is for designers or perhaps design engineers, to pretty much build Bootstrap themes. That would let me code to the Bootstrap docs (which are pretty good), while allowing us to brand or customise whatever we're working on. I've seen even contract designers push back on this idea, suggesting that doing such a thin…

I, having decades of frontend development experience, asked this of my VP once. He said no designers would work for us if we did this.

Re: Thank You Bootstrap 1

#13

Post by danpalmer »

leoqa wrote: post #10
danpalmer wrote: post #7

Something that I've often wished, as a primarily backend focused engineer, often without frontend support, is for designers or perhaps design engineers, to pretty much build Bootstrap themes. That would let me code to the Bootstrap docs (which are pretty good), while allowing us to brand or customise whatever we're working on. I've seen even contract designers push back on this idea, suggesting that doing such a thin…

Most companies will have a team building a component library which is equivalent.

Functionally no companies have a team building component libraries.

Tech companies with >100 employees might be more likely to, but that leaves most companies without that team, where they may still benefit from using Bootstrap as the basis for it.

Re: Thank You Bootstrap 1

#14

Post by danpalmer »

BillSaysThis wrote: post #12
danpalmer wrote: post #7

Something that I've often wished, as a primarily backend focused engineer, often without frontend support, is for designers or perhaps design engineers, to pretty much build Bootstrap themes. That would let me code to the Bootstrap docs (which are pretty good), while allowing us to brand or customise whatever we're working on. I've seen even contract designers push back on this idea, suggesting that doing such a thin…

I, having decades of frontend development experience, asked this of my VP once. He said no designers would work for us if we did this.

Can you give any more insight as to why? Designers always seem to want to build design libraries, I don't understand why they wouldn't want to use a common API as the basis for that so that there's a contract of sorts with developers.

Re: Thank You Bootstrap 1

#15

Post by caspper69 »

danpalmer wrote: post #7

Something that I've often wished, as a primarily backend focused engineer, often without frontend support, is for designers or perhaps design engineers, to pretty much build Bootstrap themes. That would let me code to the Bootstrap docs (which are pretty good), while allowing us to brand or customise whatever we're working on. I've seen even contract designers push back on this idea, suggesting that doing such a thin…

Having spent a decade in the late 90s / early aughts doing PHP web development (including Bootstrap), I can't for the life of me figure out why modern frameworks need hooks and a shadow DOM and a component model.

I dabbled for a bit about a decade ago, and the first and last JS framework I worked with was Angular2 (which was in beta); this was right about the time Typescript was getting started (in fact, I distinctly recall that a substantial number of popular JS libraries didn't even have TS bindings at that time).

I think I didn't really want to look stupid by asking in public on HN, but given recent events, I think that ship has sailed :)

Other than analytics, what in the world do we need all of this JS for? I used jQuery (sparingly I might add), and it did its job.

Most web forms don't even have that many components.

I honestly don't mean to insult anyone, and I know I must just be naive about something.

Because otherwise, HTML/CSS aren't that complicated. Messy? Sure. Large? Yup. Duplicative in areas? 100%.

So what am I missing? What exactly does React do so well that the added complexity and resulting slowdowns become an acceptable tradeoff?

Re: Thank You Bootstrap 1

#16

Post by krab »

caspper69 wrote: post #15
danpalmer wrote: post #7

Something that I've often wished, as a primarily backend focused engineer, often without frontend support, is for designers or perhaps design engineers, to pretty much build Bootstrap themes. That would let me code to the Bootstrap docs (which are pretty good), while allowing us to brand or customise whatever we're working on. I've seen even contract designers push back on this idea, suggesting that doing such a thin…

Having spent a decade in the late 90s / early aughts doing PHP web development (including Bootstrap), I can't for the life of me figure out why modern frameworks need hooks and a shadow DOM and a component model. I dabbled for a bit about a decade ago, and the first and last JS framework I worked with was Angular2 (which was in beta); this was right about the time Typescript was getting started (in fact, I distinctly…

You split your app into components and separate it from the backend using an API. This allows you to build a bigger development team. The result will be less efficient but more featureful, more polished, will have someone on call and a better bus factor.

It's a trade-off.

Re: Thank You Bootstrap 1

#17

Post by zoomTo125 »

danpalmer wrote: post #7

Something that I've often wished, as a primarily backend focused engineer, often without frontend support, is for designers or perhaps design engineers, to pretty much build Bootstrap themes. That would let me code to the Bootstrap docs (which are pretty good), while allowing us to brand or customise whatever we're working on. I've seen even contract designers push back on this idea, suggesting that doing such a thin…

Every bootstrap site looks the same no matter how you customize it. Designers quite often focus on the details. They're the type of person who gets offended if the icon is off by 1 pixel. It is fine for most of us with no artistry brain, but may be boring to see the same bootstrap theme for them. Anecdotally, it is like clothing choice in different gender. Majority of men are fine wearing the same tee everyday, but most women prefer to wear different styles of clothes on each day.

Re: Thank You Bootstrap 1

#18

Post by caspper69 »

krab wrote: post #16
caspper69 wrote: post #15

Earlier quoted context omitted.

Having spent a decade in the late 90s / early aughts doing PHP web development (including Bootstrap), I can't for the life of me figure out why modern frameworks need hooks and a shadow DOM and a component model. I dabbled for a bit about a decade ago, and the first and last JS framework I worked with was Angular2 (which was in beta); this was right about the time Typescript was getting started (in fact, I distinctly…

You split your app into components and separate it from the backend using an API. This allows you to build a bigger development team. The result will be less efficient but more featureful, more polished, will have someone on call and a better bus factor. It's a trade-off.

I don't mean to be obtuse, so let me make sure I have this right (and please afford me some leeway on my gentle ribbing, I assure you it's all in good fun and nothing personal):

A framework will allow me to separate the app from its backend?

The web, by its very nature, runs on a client/server architecture, so it has long been possible to separate the front from the backend via an API (we can argue the level of difficulty involved, but I would say the friction was substantially reduced with the introduction of XMLHttpRequest).

So aside from separation via API, according to your list, that leaves us with (1) a bigger development team; (2) a less efficient result; (3) a potentially more polished result (I added possibly, because I'm dubious about the claim that a JS framework makes the result more polished- does it make the browser render the HTML components in a higher resolution or higher color bit-depth?); (4) someone on call (like an employee or group of employees who have to be on call at all times? or am I misunderstanding?); and (5) a better "bus factor" which is a term that I am actually unfamiliar with (is this jargon, or is it an actual technical term/concept?).

Which of these are technical in nature, or rather I should say, which of these factors has anything to do with software (in the abstract) or actual code or markup (in the concrete)?

Now for my more serious follow up: just level with me; is this all bs? Do people use these frameworks because they don't know any other way to do it? Is it a code / organizational issue? Did people take the "separate all code from all HTML/CSS" advice too far and adopt it as dogma? Do people find the event model in JS to be too complex or unreliable? Is it an issue of people getting hooked on frameworks while JS was in flux so they needed the polyfills? Is it that people fell in love with TS, which naturally led to framework-itis?

I feel kind of like I went to the future, and everybody rides exercise bikes everywhere they go to stay in shape, but since exercise bikes don't go anywhere, they have to be put in the bed of a pickup truck first, you know, to actually go places, but then there was a gas shortage, so it was decided to save gas we'd all carpool by putting 5 pickup trucks on a single semi-truck flatbed. Because that's just how things evolved.

So now you're explaining to me why I see people riding exercise bikes on top of pickup trucks that are themselves being pulled 5 at a time on the back of a semi truck, and you're looking at me like I'm out of touch because I can't figure out why you guys can't just walk the 250 feet to the store across the street.

Re: Thank You Bootstrap 1

#20

Post by chillfox »

caspper69 wrote: post #18
krab wrote: post #16

Earlier quoted context omitted.

You split your app into components and separate it from the backend using an API. This allows you to build a bigger development team. The result will be less efficient but more featureful, more polished, will have someone on call and a better bus factor. It's a trade-off.

I don't mean to be obtuse, so let me make sure I have this right (and please afford me some leeway on my gentle ribbing, I assure you it's all in good fun and nothing personal): A framework will allow me to separate the app from its backend? The web, by its very nature, runs on a client/server architecture, so it has long been possible to separate the front from the backend via an API (we can argue the level of diffi…

"bus factor" is just a side benefit of having a larger dev team. The idea is if someone gets run over by a bus then you still have someone who "knows" the code to train the replacement.
Post reply on HN