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.
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.
I disagree. I can relate to application setup and deployment feeling like its a fragile, error prone process but library usage in general is a good thing. Now if you're picking up obscure, poorly maintained libraries from GitHub I can see that going south quickly but as long as you're smart about not only which dependencies to choose from whom but also knowing when you really need them then you end up with a robust, easy to maintain system in the end.
The whole point of having a dependency chain is to benefit from well tested code that often does mundane things that you neither have the time or expertise to create yourself. I've found that as long as I choose libraries that are up to date, look to be maintained, are decently tested, and do something that I couldn't do as well or don't have the time to implement as well then all is well. I also have a rule that if a dependency is at all mission critical or not easily replaced I will either fork that library and maintain my own copy or create one for myself.
This has been true for every language I've worked with. Go, PHP, Node, or Ruby so far.
Updating might be cumbersome but if you're following best practices then you've got tests that ensure updating a library won't break your code. You also don't go around mass updating things. You update when there's a good reason to (security patches, language compatibility, etc.). Deployment should only suck the first time. Nowadays we have tools to ensure systems are replicable so you can be confident code will run fine regardless of the environment.
I don't think we'll ever have a plug and play experience. We have so many hobbyist libraries precisely because our languages and tools are so flexible. Hiding complexity is what programmers do for users. To hide from developers too would likely do more harm than good and result in a generation of programmers who don't understand how their systems really work. I point to Rails and Meteor as examples. There are Rails developers who are a thing in and of themselves. They're not Ruby devs who know Rails, they're just Rails developers. There needs to be the person like the Rails core team who know how to put dependencies together in a way that creates a functional modular system.
I don't see the benefit. It seems no easier on the eyes than JSON and it's more complex with more syntax rules to learn. I wouldn't recommend this for either humans or machines. HJSON would be my choice for a human readable data notation format.
Haven't tried it. I don't think I would as its a SASS project and I prefer LESS. My initial thought just upon glancing the readme was that it seems a bit bloated. Starts out with some great options then it looks like they've defined variables for every system don't imaginable. I like typebase because it's a very complete base that you can customize and build on without having to tear apart. Typographic seems more framework-y which is a turnoff for me.
But that's just a first impression and my needs and preferences aren't everyone else's.
I've been using this as the basis for my typographic styles for maybe a year now. My only problem with it has been the spacing between paragraphs and headings. I find myself using the .hug class a lot.
Most people don't disable JavaScript but beyond that edge case (I consider JS disabled an edge case) I agree that this architecture isn't necessary and overused. A single page app is great on a MacBook Pro with 2 tabs open but run that on most "normal" people's machines and it gets laggy quick.
People always mention disabled JS and SEO as pitfalls but I think performance and practicality are the obvious reasons not to do this that get overlooked. SPA architecture is something I use alongside server rendered pages. When you have one page or a series of pages in a particular user flow that would benefit from no page reloads and are heavy on interactivity then it makes sense but otherwise I can't see the value. I think developers will realize this and take a more balanced approached with a practical mix of pages rendered server side and pages that use XHR and JavaScript to enhance the experience.
Great suggestions for non-technical people in there but if a real concern is ownership and control of content then the only real option is buying or renting server space and putting up a website with maybe Ghost (the most overrated blogging platform ever) or the open source Wordpress or just plain HTML. All the other options listed still could potentially shut you down for some weird TOS violation (like if you're a big KKK supporter or something). Is it likely to happen? No. But isn't this where we post our overanyzed takes on everything?
The process is the same for those with sleep apnea who aren't overweight. Like me. I weigh 155 and an 6' tall. Born with a small airway and just got lucky it seems. So if your point is that if people just lost some weight they wouldn't have anything to complain about then I'm not sure weight is even relevant here. It's a very lengthy and time consuming process regardless of the cause.
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.