Renner1

Dapper does have very low-level basic functionality to insert or update entities. You need to write the SQL yourself so this gets very painful very quickly for complicated models where you want to persist child objects.

That someone would say "Dapper is all they need" leads me to think they only work on very small projects. You will drown in large projects if you use Dapper everywhere. Better to use a high level ORM like EntityFramework and sprinkle in some Dapper in performance critical code.

The only time EF creates performance problems is when the developer doesn't understand the concepts behind SQL. This isn't an ORM problem, it's a training problem.

I agree with your point and disagree with redux-form being a valid solution. redux-form creates a very restricted and crippled API for getting form data into a redux state object and does so at the expense of the spirit of React's componentized model. Any redux-form state needs to be isolated under a special root object specifically for forms. You can't just mount some existing part of your state object into a form because of this. Not to mention redux-form properties have a whole bunch of other "glue" properties in addition to the actual value of the form.

I question whether people use it in large scale production. This is one of the huge downfalls of redux. It makes some things easier, but it makes the most fundamental stuff (editing form fields) extremely contrived. This is the main reason I don't see react+redux as a true answer to the challenges of SPA development but a very rough, intermediate step which needs to be re-thought while putting into consideration the most common use cases.

It's disappointing to see this level of incompetence from a group responsible for such great leaps in web security. Let's Encrypt should take appropriate steps to ensure this never happens again lest they erode users' trust any further.

> If postgres does it for you, don't go bashing everything else that tries to be an alternative I feel.

People bash on MongoDB because they care. People just want to raise awareness that there are two types of MongoDB users: Those who understand it is a deeply broken system, and those who haven't used it thoroughly. The truly careless and anti-social approach would be for people to leave no negative comments about MongoDB and let others fall into the same trap.

At the risk of beating a dead horse, we are only fueling the flames of javascript fatigue by churning out these "It's like X, but with more/less cowbell" libraries. We need to stop fragmenting and start doubling down on existing libraries.

A year ago I reviewed most of the popular "Self-hosted 'Cloud'" packages and found they all had pretty ugly history (security vulnerabilities in particular) and the technologies used didn't inspire confidence in the developers (when data security and integrity are on the table, PHP developers wouldn't be my first choice, nor any choice).

Are there any decent tools out there today or is it still the same situation?

Clickable link: https://github.com/dotnet/cli/pull/2145

Sorry, I should have made the thread link directly to that issue.

> jury duty, a state-mandated intrusion into my most private information and thoughts

Which aspect of that statement do you find satirical?

Jury-duty forces someone to have an opinion on record about some contentious topic. By most accounts that is an intrusion into one's private information and thoughts.

I am saddened that we live in a time where people surreptitiously photograph others in public without any thought to ethics. I know it's legal and people should have no expectation of privacy in public but it's tragic to see this gradual erosion of common-courtesy privacy.

The fact that one person hasn't experienced these issues doesn't invalidate my argument. I am sure some people will have no issues, but there will be some percentage of people who do have issues and I suspect that percentage will be quite large. I also suspect a lot of people who have not encountered issues aren't actually building software for an employer. As someone else mentioned, a lot of the more vocal people tend to be unemployed hobbyists who have no deadlines or who don't venture off the beaten path because they don't have any requirements.

I am concerned that .NET Core has put .NET on a very dark path.

It feels like the developers have built this from a theoretical programming paradise point of view: Everything's "just" a handler in a pipeline. All dependencies are now "micro". Nothing has a hard dependency on anything else.

The result of all this is a framework that might be beautiful at it's core, but becomes gradually more prickly as you get closer to the development surface. It feels like their answer to usability is "Oh, we'll just throw together a metapackage for that." It scares me that they think they can wrap up all the complexity they've created in a way that won't lead to the developer having to dig through the .NET source to make stuff work.

It's worrisome to see how brittle the system is at this late stage. It shows that this has been built from the inside-out rather than outside-in with a focus on usability. All the ugly stuff that should be buried inside the framework has been pushed out to the edge of the system for the developer to deal with. Watch any of the recent ASP.NET streams to see numerous illustrations of this whenever they open up a Core project.

ASP.NET used to be a reprieve from all the hideousness of other tools like NPM and Node. Now I'm seeing all the same problems in ASP.NET. Have you tried deploying a DNX / Core app? Good luck if any file path is longer than 255 characters. Tried pulling in the dependencies from a project.json behind a corporate firewall? Good luck. It might work half the time, but it needs to work 100% of the time to be practical.

All these tiny metapackages will lead to dozens of projects all in intermediate undefined states whereas in the past we had a clear distinction - that repository from 2010? It's MVC3. Ok, we know how to upgrade that because the process is well-defined. I expect ASP.NET core will be more a case of deleting out all your semver numbers from project.json, executing the update command and holding your breath. I dread this the way I dread opening any Javascript/NPM project that's more than a year old.

Given the rise of Javascript clients with REST servers I question whether it's even worth sticking with Core when other languages can do the same thing with fewer pain points. I really want to see Core succeed but I'm just not sure about it given what we've seen so far.