3 ms·

Hmm, not client side I haven't. Wouldn't it be easier to draft a set of design principles for the project? What I mean is if you really need a single page appl

by Kequc 10y ago

Hmm, not client side I haven't. Wouldn't it be easier to draft a set of design principles for the project? What I mean is if you really need a single page application, and usually you don't, that can be accomplished easily with turbolinks. If you really need to build DOM elements on the fly, that can be done really easily with raw JavaScript, which is fairly powerful on its own these days. I just don't see it.

qud 10y ago
Completely agree (read this after posting my comment above). Having rules about structure & organisation rather than frameworks that would have their own rules seems much more pragmatic.
Shengbo 10y ago
Give this article[1] a chance if you have the time. [1]: http://jlongster.com/Removing-User-Interface-Complexity,-or-Why-React-is-Awesome http://jlongster.com/Removing-User-Interface-Complexity,-or-...
ux-app 10y ago
> Wouldn't it be easier to draft a set of design principles for the project? Isn't this what a framework gives you out of the box? Hiring should become easier if you can simply hire another Angular dev to join your large team. I'm assuming that your in-house design principles won't be as thoroughly battle tested as something like Angular or React is which has received tens of thousands if not millions of man hours of testing and refinement over the years. I'm not really advocating for or against, since I've never used a large framework like this in a team environment, but there must be benefits. Lots of smart people aren't using it because they are dummies that can't do better.
- Kequc 10y ago
  puts on tinfoil hat I think the companies that are doing it are fighting over the space the same way operating systems do. Android, iOS, Windows. Potentially apps could start being developed for Angular and React and so on, in the future which are tied to licensing contracts for users. All the smaller frameworks are people trying out a few things, none of them corporate or free are really necessary.
JoelBennett 10y ago
I suppose in a sense, it's easier to enforce policies through a library than it is to tell a dev "do this" or "don't do that'". I'm not a front-end developer either (so my JavaScript experience is a bit limited), but with the back-end code that I work on with my team, enforcing policies can be a bit tricky. It's pretty easy for things to slip through in a pull request that are against policy, and it's kind of hard to automatically check for policy violations. When forcing someone to use an API, at least you can somewhat guarantee that the API follows the policy.

by Kequc 10y ago

qud 10y ago

Completely agree (read this after posting my comment above). Having rules about structure & organisation rather than frameworks that would have their own rules seems much more pragmatic.

Shengbo 10y ago

Give this article[1] a chance if you have the time. [1]: http://jlongster.com/Removing-User-Interface-Complexity,-or-Why-React-is-Awesome http://jlongster.com/Removing-User-Interface-Complexity,-or-...

ux-app 10y ago

> Wouldn't it be easier to draft a set of design principles for the project? Isn't this what a framework gives you out of the box? Hiring should become easier if you can simply hire another Angular dev to join your large team. I'm assuming that your in-house design principles won't be as thoroughly battle tested as something like Angular or React is which has received tens of thousands if not millions of man hours of testing and refinement over the years. I'm not really advocating for or against, since I've never used a large framework like this in a team environment, but there must be benefits. Lots of smart people aren't using it because they are dummies that can't do better.

Kequc 10y ago
puts on tinfoil hat I think the companies that are doing it are fighting over the space the same way operating systems do. Android, iOS, Windows. Potentially apps could start being developed for Angular and React and so on, in the future which are tied to licensing contracts for users. All the smaller frameworks are people trying out a few things, none of them corporate or free are really necessary.

JoelBennett 10y ago

I suppose in a sense, it's easier to enforce policies through a library than it is to tell a dev "do this" or "don't do that'". I'm not a front-end developer either (so my JavaScript experience is a bit limited), but with the back-end code that I work on with my team, enforcing policies can be a bit tricky. It's pretty easy for things to slip through in a pull request that are against policy, and it's kind of hard to automatically check for policy violations. When forcing someone to use an API, at least you can somewhat guarantee that the API follows the policy.