bpatrianakos

I think this only applies to people implementing their apps using SOA as pat of cargo cult thinking like was mentioned in the article.

I ran a company with 4 employees. 3 developers and an idiot sales guy. SOA made perfect sense from the start. We had daemons running background tasks on our servers in Go (the best tool for that job), a separate data API we used for our main "monolithic" web app, and then our mobile and other clients all used the data API.

The developers working on the web app only had to know the API end points to get data into the "monolith" and the rest of us working on the API and daemons understood how all the other clients would use them. No issue.

I'm all about the idea that you shouldn't implement an SOA because successful companies do it but I feel like this article is recommending building a monolithic rails app or something as a reaction to how popular and talked about SOA architecture has been lately and doesn't really leave much room for the idea that small companies (even really really small ones) can use it and would it would make sense for them.

I couldn't agree more about the mass market being morons. It's hard to say and not often said so bluntly in public though. Not because it's untrue but because the person saying it could be afraid they might be a part of that group of morons. I can't tell you how many times I've heard a moron call everyone else morons. So is there ever any way to know when "the mass market are morons" means what it says literally or when it's a stand-in for "most people aren't agreeing with my strongly held beliefs".

I don't see a need for the snark. I don't see this as a troll question at all. Python is obviously thriving for scientific programming but it's not hard to tell that the question being asked is about whether Python is losing popularity as a general purpose web programming language.

If someone wanted to get into building web apps would Python be a good choice?

The answer is likely to be colored by your experience. I'd say yes, it is losing ground to other languages in the context of programming for the web. The people who use it know why they're using it. Othetwise you don't see many coding boot camps teaching Python. It's all about Ruby and Node.

But is Python dying? Not by a long shot. It's just getting less attention right now because of some of the other new toys that are making a lot of noise right now.

But this is specifically marketed toward developers and designers. So my question is are there really enough of those developers and designers interested in a WYSIWYG took or would it be better to drop the Bootstrap focus and focus on the small business owners and content creators?

Is there a big market for WYSIWYG apps for developers? I think this is a great application but might it be better targeted toward non-technical people? Remember iWeb? This reminds me of a more developer-centric, flexible version of that. But no developer would actually build with it. It was for the people who now use Wix, Weebly, and Squarespace for their websites.

Developers should be able to put together a Bootstrap front end just as easily in code and probably prefer working in code.

Maybe there's a huge developer market for this and I just happen to not know anyone who'd be into this.

I'd argue the barrier is just as high. I taught a ten week course in back end development and I think the students would have done equally well deploying on a VPS or Heroku.

The curriculum called for using Heroku but I regret following it now. Heroku bills itself as being easy for a beginner but go ahead and try to deploy any simple Rails or Node project using their guides. Half the time something goes wrong. Either you need extra dependencies or you have to do extra configuration that the setup instructions didn't mention. In the end you have to look up how to check the logs and even if you get that far a beginner has no clue what those logs are really saying. Even as an experienced senior developer, I couldn't get the demo project I was showing them deployed without a ton of hassle and 4 attempts.

So while it may seem like a VPS has a lot more moving parts, it's a better deal overall. Same level of confusion and complexity for students but in the end they at least know a bit about how a server works (which Heroku hides) and it's way cheaper even with SSL. I could have run that same project for $30 up front and $10 monthly.

I think it sums up the Beginner Community in general, not the JS community. You see this with beginners in everything.

No SQLite isn't heavy but I hope you mean for use in development only.

The issue isn't MongoDB is bad and relational DBs are awesome. The real issue is new developers being taught that Mongo and NoSQL in general are the databases you should be using with Node. The problem secondary to that is devs not knowing when each is appropriate.

This is great but it really only applies to SPAs. I know single pagers are all the rage these days but it often makes a lot of sense to structure your application in a hybrid way where you have full page reloads for different sections of a site and each section is a container for a different SPA. I've got a decent setup for this but I'll be damned if I can find anyone who shares their setup for this sort of use case.

CSS is not a programming language. You can't think about it the same way you'd think about your backend code or even client side JS. The global namespace is by design. It's a feature, not a bug. The whole point is to think about the Cascade. You go from vague to specific and that way you have entire classes of elements with base styles and specific components have additional styles attached.

CSS modules is a cool idea but I don't think there's anything wrong with CSS as it stands today. When you work in any language you need to understand and work with the language you have and I think that a lot of criticism of CSS boils down to "CSS doesn't work like this other language/paradigm I know and like".

These are all great ideas. The only thing I don't like about these types of projects/guidelines is the almost religious, strict adherence to them that some people who pick them up like to rant about.

The examples are great and realistic but they will inevitably break down in any project with just a moderate amount of complexity. When this happens I see people decide that they've done something wrong and think they either need to restructure the UI to fit the guidelines or find a different set of guidelines to fit their project. Both are wrong.

After years of studying these guidelines and trying to perfect the perfect, most efficient, small, and understandable set of CSS styles I've come to the realization that we need to simply accept that there are going to be exceptions and that's okay. Yes, think in components, give classes sane names, don't use ID attributes, etc. but also know that at some point you're probably going to have to break a rule and it's not the end of the world. Think about the problem for a few minutes but don't waste your time trying to shoehorn your front end code to fit a set of guidelines so you can feel superior because of your strict adherence to RCSS or SUITCSS or whatever. There are more pressing issues than a few unused or single use classes. If you can follow the rules more than 80% of the time then I say you're as close to perfect as you'll ever be. Anything else is reaching for an impossible standard.

It's funny that the stricter you adhere to some of these guidelines the less productive you become as you spend more time thinking about how to create components so they fit the rules rather than getting the damn styles to look however you want.

My point being this: I love all the different philosophies and think they're all worth studying but let's be realistic when it comes time to implement stuff.

They won't do it on their own because there's really no incentive to make this information easily accessible. Healthcare is like Microsoft and Oracle in the 90's. Everyone wants you locked in to their platforms and services. Add to that the fact that you're constantly dealing with incredibly sensitive information on the level of financial data (arguably even more sensitive) and it gets worse. In finance you have PCI compliance to deal with. It's tough but not as crazy as $50k fines for every instance of leaked data with HIPAA.

Having done exactly this type of integration with legacy systems I think a point that gets glossed over is that it's the startups themselves who are full of engineers who think that the whole world has moved on to using NoSQL Node.js RESTful JSON APIs in the cloud (that buzzword soup was intentional) when the reality is that the majority of established businesses are using unsexy and what they would consider to be "legacy" technology.

So you have companies like one I was recently a part of integrating a Node web app and API with SOAP and SAML end points and suddenly it's everyone else's fault that things are hard when really you probably should have thought through those tech stack choices before you started.

I'm not saying the article is wrong. I agree with it wholeheartedly but there's a lot to be said for not researching the market you're about to jump into thoroughly enough before you begin.