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.
The article is simply reinforcing the idea that there is an alternative, and monolithic applications are not some kind of "outdated technology". Both SOA and monolithic applications are useful in different circumstances.
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".
>>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".
Absolutely there is. We have a measuring stick with which we can measure the validity of one's beliefs: empirical evidence.
If you believe X, and scientists say we have sufficient empirical evidence that confirms that belief, and the mass market doesn't believe X, that makes the mass market a bunch of morons. This is inarguable.
There are many kinds of evidence and many ways to interpret it - and many kinds of science (physicists disagree with each other less than economists for a reason.)
Incidentally, most "morons" disagree with you on matters where they can find a scientist on their side, or on issues of morality, or on inconsequential matters (like the origin of life, which is interesting to most but doesn't affect any practical decision.) Few "morons" jump out of windows in defiance of gravity, and those who do no longer bother you on Twitter.
Also, scientists err, falsify results, cherry-pick them, etc. Of course, so do "morons"...
Well said. Even when science means well, it can suck to be on the non-moron side.
For ~120 years, science "knew" that an element existed inside all ignitable substances that was released during burning. When the air was fully saturated with phlogiston, the burning stopped. Just put a candle in a jar and watch what happens. The theory's sound, right?
120 years is a few lifetimes, who knows what revelations will drop before the 21st century winds down?
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.
Amongst what bubble of people you're entangled with?
I consider this a troll question because frequently I see HN questions like this completely disconnected from programming communities at large (which do not participate in HN), extrapolated to the wider web of all programmers. By this factor alone I'd expect Java to be completely obsolete by now.... but obviously no one is oblivious enough to reality to suggest that.
As for that question, if you want to build webapps right now, then yes, Python, as well as Ruby, and PHP, would be absolutely fantastic choices. The library ecosystems for all three of these are incredibly rich, mature, and well supported. Choose the language of these 3 that appeals to you the most, you will not be disappointed. I'm not going to tell you which one to choose, I think you'll be happy with whichever of these 3 languages appeals to you the most.
If you don't mind filling in the occasional gap, and like the bleeding edge of newness, try Rust, or Go. I've done both, they're fun languages with interesting paradigms (built-in lightweight threads vs. memory-safety at all costs FIGHT!).
Getting less attention? According to what? Did you see the the link about dominating science? Attention according to what group of people?
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.
There is a whole spectrum of people who work "on the web" in some form or another: hard-core developers, front-end coders, designers, small business owners, content creators, etc... So any tool from Squarespace to BootstrapStudio to Emacs is potentially useful to a subset of the market.
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?
> But this is specifically marketed toward developers and designers.
"Developers and designers" encompasses quite a range of skills. Many designers don't know how to code or don't want to deal with it, or would rather do it in a visual editor rather than in a text editor.
On the other side, there are developers who aren't proficient in modern HTML, CSS, web technologies, and the obnoxious-to-set-up modern web tool chain. A GUI like this could be a handy way of bypassing some of these problems so they can get that website built quickly without it looking like it belongs on the 1990s web. (I admit this case is more rare.)
> would it be better to drop the Bootstrap focus and focus on the small business owners and content creators?
I agree with you there, and that's actually what I'm working on. In my application the web developer/designer can create custom "components" with HTML and CSS and some rules on how these components can fit together, and the site owner / small business person / content creator can manipulate their site in a completely visual, drag-and-drop, edit-in-place environment. There are no mandatory tie-ins with any frameworks or libraries, and the system doesn't alter your markup or insert additional junk. Any valid HTML and CSS the developer puts in will work and will come out essentially as entered.
Yes, there are plenty of developers who pay good money for Dreamweaver or similar, and a great many more who would like to but don't think the tools are good enough.
Likewise many developers pay for point and click IDEs even though vim is free.
I would. I'd love to be able to load a specific theme/framework/css and have html/css written up for me. I don't mind the under-the-hood programming, and I even like designing, but writing up HTML/refreshing/css-ing/refreshing to match my design goals is really frustrating for me. The worst of coding, while simultaneously taking the joy out of the creative nature of design.
Same thoughts, i am a coder. I would never touch such Software. I still write the most correct HTML for my eyes and i am faster than anything else could be.
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.
Many pet projects you can run for Free on Heroku. Their docs are pretty straight forward, not sure what your hiccups were but I've deployed quite a few sites to Heroku without much if any issues.
The asset pipeline in rails use to cause some issues but I think that has all been resolved with the 12 factor gem.
Also setting up a VPS is in no way easier than Heroku. You have to install nginx, ruby, mysql etc. Then you have to setup routing. Then you have to learn all sorts of sysadmin stuff so you don't get hacked. Setting firewall permissions, mysql permissions. Then you want to deploy that app. So you have to setup capistrano or whatever. Next thing you know day wasted.
Instead of spending money on a vps for my last side project, I went the heroku route and it was even easier. I spent 7$ on a private github repo.. which synced to heroku. And a free CircleCI account that also synced up with everything. Then just pushing my branch meant, automated testing and with heroku pipelines, a PR meant automatic test env.
Using AWS Elastic Beanstalk you can deploy by zipping a folder of your code and uploading it using a webpage form. The barrier for entry on cloud infrastructure is really low.
That's not the "right way" but arguably nor is using a Heroku box with no idea what's actually running on it.
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.
It's actually commonly used in production for certain types of databases. SQLite is not a replacement for something such as postgresql but it certainly has it's use cases.
The use case for SQLite isn't high traffic public facing webpages. Here is their own list of 'famous' users: https://www.sqlite.org/famous.html
Every iPhone, and Android phone have SQLite running on them, which easily makes it the most used production database. It's use case is typically very low traffic websites or as client side storage.
Maybe I'm missing something but is Mongo in use on the client side in that same way? If not then SQLlite is being shoehorned into the discussion and the context in which production was used should be clear. I feel like people are trying to be technically right instead of following the actual discussion. I never meant client side software and definitely didn't mean someone's micro traffic blog, where a toy database could be used.
It is interesting how much penetration SQLlite has on the client, though.
At any rate, I know better than to not be extremely specific so I brought this on myself.
It seems like there have just been some assumptions going both ways.
This all started when someone trashed RDBMS for being "heavy", implying that Mongo is good because it's light.
Why would you care how heavy a DB is if it's not on the client side? The kind of memory and storage you need for even the heaviest popular RDBMS (MySQL?) is still low enough that's nearly free to create a small app.
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".
No, CSS isn't a programming language, but that doesn't mean it can't use functionalities that are typical of programming languages - just look at variables, functions, arrays, maps and other features that preprocessors like SASS have brought us.
While some approaches are a matter of taste/habit, I think there's an extremely wide consensus that having everything available in global scope is bad.
If the global namespace really is by design, then why are we adopting conventions (such as the one in this very topic) that mostly aim to defeat it? Prefixing class names to apply them only to a specific component is nothing but a primitive way of limiting scope.
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.
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.