Well done. I work in a large enterprise and have no design ability. Tired of banging bootstrap together and not quite getting the look you achieved with Flakes. Looking forward to trying this.
Show HN: Front-end framework optimized for internal apps
71–80 of 94 posts
Re: Show HN: Front-end framework optimized for internal apps
#72I wish more things looked like this at work. There's apps that look like native apps, there's bootstrap apps, there's all the custom CSS floating around, there's whatever's new, there's the stock CSS sheet that comes with the plugins... Keeping to principles like this at work or for work environments would make it so much easier to have unity. I'm not saying everything should look like this, but that not everything n…
I work at a very large company and it's the same way. We have a team dedicated to keeping internal apps within certain stylistic and functional guidelines but the overall landscape is still an absolute clusterfuck. Some apps are built with bootstrap, some with pure, some with no styling whatsoever, different hexes for our company's primary color... you name it. Fragmented as all hell.
Re: Show HN: Front-end framework optimized for internal apps
#73Everytime I see a new CSS framework with a grid layout (which they all do) I get sad that decent cross-browser support for the CSS Grid module seems so far away...
It doesn't matter if all the company PCs are running the same software.
I'm thinking about it from the perspective of an ISV that wants to deliver a app with a web interface that is run on in-house servers. Although we could probably just target the capabilities of IE (which does support an early version of the CSS Grid spec) and be done with it...
Re: Show HN: Front-end framework optimized for internal apps
#74Just wanted to mention that I work on NimbusFoundry(nimbus foundry.com) which has similar ideas except we focus on auth, storage of data, and permissioning instead of front end. This is so that users can create apps within enterprise environments like Google apps for business easily.
Re: Show HN: Front-end framework optimized for internal apps
#75I really like gridforms for dense data-entry forms ( http://kumailht.com/gridforms/ ).
Was coming here to say the same earlier, but I liked it so much I've now hacked together a sweet DSL to use it with my React form library.
Rendering demo: http://insin.github.io/newforms-gridforms/
DSL example: https://github.com/insin/newforms-gridforms#usage
Re: Show HN: Front-end framework optimized for internal apps
#76What about OpenUI5 for business apps: https://openui5.hana.ondemand.com/#content/Controls/index.ht... From my initial tests, it's very clean MVC (a bit verbose). Also the deploy story is not too good... (frontend code ships as a .war). Does anyone have experience with this, good or bad?
It's relatively clean, but a bit more klunky feeling. It also seems REALLY sluggish... Not sure if this is typical, but it really doesn't feel nice. I'm also not a huge fan of enterprisey software development.. SAP and most Java projects make me pull my hair out just getting an environment for development setup.
Yeah the other day was my first day with Java and Eclipse and I was close to pulling my hair out (coming from python and vim). Ultimately it's just a different set of batteries but the depth/weight of the stack seems insane---the expression 'house of cards' comes to mind...
Still OpenUI5 is just js files in the end, so hopefully entreprisey people can't mess it up too bad ;)
Re: Show HN: Front-end framework optimized for internal apps
#77Just wanted to mention that I work on NimbusFoundry(nimbus foundry.com) which has similar ideas except we focus on auth, storage of data, and permissioning instead of front end. This is so that users can create apps within enterprise environments like Google apps for business easily.
Very cool - I like your idea to store all of the data using a Google Drive realtime document. But I'm not sure how you are able to handle authentication and permissions, e.g. limiting a field/model to only be visible to certain users. AFAIK read access to a document in Drive is all-or-nothing, and there doesn't seem to be a way to let a user only view a portion of the document. Are you only enforcing the access control in the client-side logic? If so, that's not even remotely secure....
Re: Show HN: Front-end framework optimized for internal apps
#78Not sure why Bootstrap bloat is a problem if it's just going to be an internal app. I'd rather go with a more familiar, and well known framework, and not have the overhead of learning yet another framework (not to mention others who would maintain or contribute to the internal app would have to pick up this new framework)
That being said, I do like the look and feel of Flakes. Also, given that graphs and charts are key to internal business apps, would be awesome if there was some easy charting integration / capability.
Re: Show HN: Front-end framework optimized for internal apps
#79Not sure why Bootstrap bloat is a problem if it's just going to be an internal app. I'd rather go with a more familiar, and well known framework, and not have the overhead of learning yet another framework (not to mention others who would maintain or contribute to the internal app would have to pick up this new framework) That being said, I do like the look and feel of Flakes. Also, given that graphs and charts are k…
Bootstrap bloat has little to do with it, looking at the docs. This gives you a bunch of components for specific data views; Bootstrap is far more general, requiring you to create your own components out of Bootstrap's lower-level CSS. It's a specifically geared framework vs a general one.
Re: Show HN: Front-end framework optimized for internal apps
#80Earlier quoted context omitted.
Be that as it may, this is exactly the type of form I routinely see people filling out on 80s-era WYSE terminals at airports, rental car agencies, the DMV, hardware stores, and so on. It seems like a lot non-tech people find them fairly easy to get the hang of.
What evidence do you have that people find it easy? My experience with such forms is that people make mistakes constantly. Just because awful forms are common doesn't make them easy. I'd argue that there are many easier styles of form. Old terminals were fairly space-constrained so I can understand why this choice was made, but modern computers with their high-res screens do not have this restriction, e.g the iPhone…
Speaking of the iPhone, input forms in iPhone apps are more or less grid style.