3 ms·

This feels like as a solution to the problem that does not exist. This just increases the complexity and makes the interface horribly fragmented and hard to dev

This feels like as a solution to the problem that does not exist. This just increases the complexity and makes the interface horribly fragmented and hard to develop for after a while.

hn_throwaway_99 7y ago
> This feels like as a solution to the problem that does not exist. While I'm not sure this is the right solution, the problem absolutely does exist. There are loads of companies that have to deal with extremely shitty, brittle front ends that are confronted with a difficult "scrap the whole thing and rebuild it" vs. "incremental improvements" challenge. If this tool is used appropriately as a way to piecemeal replace parts of your website, then I think it could be very useful. While I love deleting old crappy technology as much as any other developer, I've seen more than my fair share of "big bang" replacements fail miserably and result in huge team burnout and reduced trust between the business and technology sides of a company. On the other hand, I would only support this tool if the end game was indeed getting rid of all the crappy old stuff. Living in a world with umpteen different languages and ways of doing things on the front end is a recipe for extremely low productivity. Thus, like most tools, something like this can easily be misused but there is certainly a place for it if used appropriately.
regularfry 7y ago
The problem this solves is having different teams in the same company perfectly happily developing away on their own stacks when a random business requirement needs that they get their components in the same browser window such that neither team is tied to the other's deployment cadence.
- JMTQp8lwXL 7y ago
  Having worked at multiple engineering organizations, I could see how some people might question the value of this. For example, A big N company I worked at went all in on React. Top down, no ifs-ands-or-buts about it. I'm biased and like React, so I didn't mind the decision. Today, I'm in an engineering organization where we have teams using React, Vue, and Angular, with no foreseeable convergence on one. Each team feels most productive in its preferred stack. A solution like this allows us to at least ship our code together, instead of having everyone maintain CI/CD on top of their application code. It buys us additional developer productivity. We don't need to be duplicating deployment pipelines.

This feels like as a solution to the problem that does not exist. This just increases the complexity and makes the interface horribly fragmented and hard to develop for after a while.

hn_throwaway_99 7y ago

> This feels like as a solution to the problem that does not exist. While I'm not sure this is the right solution, the problem absolutely does exist. There are loads of companies that have to deal with extremely shitty, brittle front ends that are confronted with a difficult "scrap the whole thing and rebuild it" vs. "incremental improvements" challenge. If this tool is used appropriately as a way to piecemeal replace parts of your website, then I think it could be very useful. While I love deleting old crappy technology as much as any other developer, I've seen more than my fair share of "big bang" replacements fail miserably and result in huge team burnout and reduced trust between the business and technology sides of a company. On the other hand, I would only support this tool if the end game was indeed getting rid of all the crappy old stuff. Living in a world with umpteen different languages and ways of doing things on the front end is a recipe for extremely low productivity. Thus, like most tools, something like this can easily be misused but there is certainly a place for it if used appropriately.

regularfry 7y ago

The problem this solves is having different teams in the same company perfectly happily developing away on their own stacks when a random business requirement needs that they get their components in the same browser window such that neither team is tied to the other's deployment cadence.

JMTQp8lwXL 7y ago
Having worked at multiple engineering organizations, I could see how some people might question the value of this. For example, A big N company I worked at went all in on React. Top down, no ifs-ands-or-buts about it. I'm biased and like React, so I didn't mind the decision. Today, I'm in an engineering organization where we have teams using React, Vue, and Angular, with no foreseeable convergence on one. Each team feels most productive in its preferred stack. A solution like this allows us to at least ship our code together, instead of having everyone maintain CI/CD on top of their application code. It buys us additional developer productivity. We don't need to be duplicating deployment pipelines.