13 ms·

This is almost exactly the direction my team has gone. We use the MS stack (.NET Core, EF Core, MVC, SQL Server 2019, VS2019), we have rolled our own auth and l

by cols 5y ago

This is almost exactly the direction my team has gone. We use the MS stack (.NET Core, EF Core, MVC, SQL Server 2019, VS2019), we have rolled our own auth and logging, and we have written our own JS and CSS libs to handle browser interaction, adornment of basic input/select controls, and styling. While it seems like a lot of work, IMHO, the tradeoff of using an ecosystem with such a massive attack surface (NPM) is simply a pill we couldn't swallow. For those of us building systems that actually NEED to be secured, the "convenience" of using NPM isn't worth being kept up at night thinking about all the ways your app could be fubar'd.

stillblue 5y ago
I've got three questions. 1)How much JS/CSS are we talking about for heavily interactive pages? Do you not even use light weight libraries like knockoutjs or backbonejs? 2)Have you gone down the Blazor route yet? 3)What kind of system yall are working on that requires this much security? I've worked for a very information sensitive department of one of the top International banks where it was all sorts of npm galore.
- cols 5y ago
  1) We built our own event driven system for JS interactions. It does exactly what we want, when we want and comes in under a few thousand lines of code. The data transfer happens via a wrapper we wrote around the standard Fetch API called FetchWithTimeout (thank you David Walsh [0]). We also built our own animation library to handle things like graceful entry and exit transitions (e.g. when an item is deleted, it asynchronously swipes or fades out of view). All of this was done in vanilla JS/CSS. The only external library we used was a sub-1000 line library for toasting messages in the UI. We heavily extended this library and, hopefully, improved upon the original design. We also wrote our own CSS utility library. It's bare bones but it is exactly what we need. 2) We considered Blazor but went with MVC instead. Better suited to our skill set and definitely a bit more optimized when compared to Blazor (at least it was when we started our project). 3) We are building an internal-facing financial management system. We are heavy handed with our security approach but we have the time and the budget to be. We are in a unique situation where we have a lot of time in which to complete our project, so we can be really careful about building what we need. Also, since our application is internal, we completely bypass common user issues like browser compatibility (everyone uses the same browser) and complicated server infrastructure (we have sub 200 employees). It's a pretty fun project tbh. [0] - https://davidwalsh.name/fetch-timeout https://davidwalsh.name/fetch-timeout

by cols 5y ago

stillblue 5y ago

I've got three questions. 1)How much JS/CSS are we talking about for heavily interactive pages? Do you not even use light weight libraries like knockoutjs or backbonejs? 2)Have you gone down the Blazor route yet? 3)What kind of system yall are working on that requires this much security? I've worked for a very information sensitive department of one of the top International banks where it was all sorts of npm galore.

cols 5y ago
1) We built our own event driven system for JS interactions. It does exactly what we want, when we want and comes in under a few thousand lines of code. The data transfer happens via a wrapper we wrote around the standard Fetch API called FetchWithTimeout (thank you David Walsh [0]). We also built our own animation library to handle things like graceful entry and exit transitions (e.g. when an item is deleted, it asynchronously swipes or fades out of view). All of this was done in vanilla JS/CSS. The only external library we used was a sub-1000 line library for toasting messages in the UI. We heavily extended this library and, hopefully, improved upon the original design. We also wrote our own CSS utility library. It's bare bones but it is exactly what we need. 2) We considered Blazor but went with MVC instead. Better suited to our skill set and definitely a bit more optimized when compared to Blazor (at least it was when we started our project). 3) We are building an internal-facing financial management system. We are heavy handed with our security approach but we have the time and the budget to be. We are in a unique situation where we have a lot of time in which to complete our project, so we can be really careful about building what we need. Also, since our application is internal, we completely bypass common user issues like browser compatibility (everyone uses the same browser) and complicated server infrastructure (we have sub 200 employees). It's a pretty fun project tbh. [0] - https://davidwalsh.name/fetch-timeout https://davidwalsh.name/fetch-timeout