Comments URL: https://news.ycombinator.com/item?id=14000307

Points: 3

# Comments: 1

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.

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.

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.

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.

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.

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".

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.

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.

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.

But that's just a first impression and my needs and preferences aren't everyone else's.

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.