The author has probably been burned by people who use shiny/new tech just because it's shiny/new. And I guess he thought we needed a manifesto for this situation. But I agree, the "get off my lawn" tone makes it not very effective IMO.
You get a team tell them "let's do this widget" with no detail, no edge case scenario, no perf requirement. So they choose last awesome tech which solution a problem they got last time and will look good on a resume. And only after a month or two of making things do the real hurdle of this tech start appearing. All the things you never see mentioned in those "let's get started" tutorials or shiny-techs online conference.
With some time spent thinking about the problem space and what happen when things go bad your team could have sensed that nothing is all sugar and rainbows. Take micro services: at first it looks elegant. But when you start thinking about how to manage transactions for some actions across multiple services or how to handle some of your server dying then coming back to life you suddenly have the urge to stop and check if you really need this kind of architecture at first.
It starts with a list of things that everybody obviously wants, goes on to give very specific examples with absolutely no backing or evidence, and finishes with some hand-waving "you get the idea".
Also, "nor will we defend our lack of knowledge of their hyped and volatile technologies" really comes off as complacent ignorance.
The best way to try and fight something is to first learn about it. You might even learn that the thing you're fighting has some useful lessons in it.
I don't advocate for pageload-based frame works (asp.net webforms, cf, a bunch of roll your own phps, etc), and I believe a lot of the vendors of them have been kind of moving away from them toward a more bare-metal HTTP approach, but that doesn't mean they don't have a place.
In RAD and click and drag IDEs that large corporations prefer, you can hand a single Junior level developer a requirements document, and expect them to be able to build a back-office type application.
Cookies and injection attacks vs Local storage
Fat server sessions vs fat client sessions
Forms and CSRF vs XHR JSON
Let's not pretend that web tech has somehow been Nirvana at any point in the past.
While I still stumble upon SPA that can't even get navigation right.
But the main reason is still this:
I compared the serverless website (considered a state of the art SPA) with the hackernews website (considered a student level website) on an edge connection in the German country side:
- first load: 6 seconds
- next loads: 3.5 seconds
- first load: 26 seconds
- next loads: 7.5 seconds
For a webpage displaying static text.
I think a good SPA is a superior experience but a bad SPA is worse than a traditional page load approach.
It takes like 4s for me.
Though I think you're kidding yourself if you think HN is typical.
I can't see any reason why there should be anything but a very small difference on way or the other.
You are not on an edge connection then.
> Though I think you're kidding yourself if you think HN is typical.
No, but serverless and NH have the same purpose of mostly displaying text.
There are parts of current software development that really, really suck. The author does not capture them; this is "new things are scary" complaining and very little more.
Only with big players: facebook, gmail, etc.
Small crew SPA usually suck big time precisely because there is not django/ror/etc equivalent for SPA. So people write it by hand. And they don't all have the talent pool and money the GAFAs have.
(And, speaking personally, my now-standard stack of TypeScript/Express/TypeORM/tsoa provides a level of architectural enforcement I've only really gotten previously on the JVM, but with significantly less mucking around with my runtime.)
A HN clone SPA though...
First, let's see if they can get code splitting right to not make it loads 3mo/page.
Then if they can choose a stack that doesn't kill navigation.
Also, let's see how long it takes both team to come up with the same result.
My money is on the static stack. Just the registration without a good framework is plenty of fun.
Not that you can't make a SPA with an old school framework. But for some reason, SPA lovers will often go full nodejs as well, which is basically 1000 of libs you have to hand picks and fuse together.
I work on more and more SPA every day. It's always the same deal: the cost is higher, and it needs smarter devs.
Bottom line: do one when it has a good added value for your users.
NoSQL databases have been around since the 60s , and the term was created in 1998. Two decades ago. Is the author of this manifesto saying that they'll only work with tech from the 50s? Or is the 80s good enough? The 90s clearly isn't.
In fact, Ajax has _also_ been around for two decades; 1998 was a big year for the web, apparently. The Outlook Web App (a major milestone in SPAs) was created in 2000, 18 years ago.
This "manifesto" is nothing more than "I choose to bury my head in the sand and use outdated tech and ignore the state of the art!"
I think workplaces really, really should be using newer/"sexier" programming languages and libraries, but not as a blanket approach. People should be allowed to experiment and try new things, especially for projects or parts of projects that are new and exciting. This shouldn't be in lieu of existing and well-known technology.
If they are trying to imply it by giving examples of technologies that are hardly new or experimental, then that's even more cause for being explicit.
With that said, you have to be smart and know when boring is not enough. 3-tier apps are great until complexity pushes them into gnarly monolithic messes that resist change. And with some sensible UX thinking adopting SPAs can push your user experience forward. NoSQL databases might not be the best choice as your primary datastore but might be a better alternative than materialized views (Graph databases are often utilized by some organizations as part of their secret sauce)
Anybody can code a HN clone. An SPA HN clone that is not a total disgrace though ?
It's certainly popular. I wonder if sites like github would be simpler for users, developers, and devops if they just embraced SPA - judging by your comment, maybe?
Even when I worked in a boring industry like advertising and banking they expected things to be done by next sprint and were very accepting of the instability tradeoff.
I'm not saying that they're thesis is wrong: boring but stable software is a Very Good Thing, but it's not just us devs wanting to use the latest and greatest that's driving such quick tech adoptions.
I also use micro services on a daily basis, which this manifesto seems to dislike very much so I'm more of the opinion that pragmatism should be priority #1
Need micro services? good, use it
Need an ORM? why not (though use with care)
Need a relational databse ? go for it
Need noSQL? sure
Just make sure you have a good reason to pick whatever you work with, and usually the simpler the better.
They all have pros and cons and I feel this manifesto might be more of a knee jerk reaction rather than trying to solve anything
Don't get me wrong, there's such a thing as innovation for its own sake which does not add value, but there is nothing wrong with a single-page application driven by microservices. That architecture is pretty well proven and "boring" at this stage.
First, you probably don't need it. There is a scale at which you benefits from microservices more than they cost. Most companies don't have that scale.
Secondly, unless you have three 10x programmers in your team, the microservice architecture is going to add a lot of complexity that will be a burden to manage.
So as usual, it's what you get VS what it costs.
Micro services are not free.
Most teams don't have the problem that microservices actually exist to solve: a fractured org chart. Because that's when you want and need microservices--when your org chart's reporting chains are separated to the point where you need to separate functionality for human and political reasons, so as to avoid having one set of interests stomp on another. There's a geometric cost to any services; generally speaking one should be sure that the carried organizational and technical load of adding another (in the microservice-swarm pattern this load is smaller on margin but heavier in frequency, and it adds up) has positive ROI.
If you are used to thinking in one paradigm in a very rigid way, of course the other is going to be hard to comprehend, hard to use, challenging to implement, and difficult to maintain. That doesn't make one solution objectively better or worse. Pick the right tool for the job. Sometimes the right tool starts with the way the mind is thinking about the problem.
All of this can drive you insane to get 'perfect' especially when technology moves fast, and the world changes. So at the end of the day, 'good enough' is usually 'good enough'.
I feel like a lot of the advice out there about software and software philosophy are just venting steam sometimes, because, people who work with software and hardware often have to not only deal with a machine telling them the way they do things are wrong (like an error message, or just trying to figure out how to make the thing do what it's supposed to do) but also plenty of people around them, saying "this is the right way to do things". Yes, it is the right way to do things, sometimes.
If there's any principle I'd take issue with, it's "built exclusively with popular and proven tools". Perhaps a good rule of thumb, but sometimes your particular needs step off the well trodden path, and it'd be a shame to see someone clinging to this dogmatically instead of considering alternatives that might get the job done easier / quicker / ...
* vacuum tubes over transistors
* goto over functions
* inheritance over composition
* your favorite last decade best practice here
This manifesto just moves the argument to what industry best practices are (hint: it's not page reloads for every single interaction for most things).
Tell me that mobx is simple. Or vue. Or jQuery.
Redux is not simple. It's basic.
In short, embracing a framework based on hype is not a great move. But neither is rejecting a framework just because it has hype.
>3-tier applications vs. micro services
As yes, the volatile and unknown territory of the architecture formerly known as "Service Oriented Architecture" that has been in use since at least the early 2000's.
I get what this guy is trying to say, but examples like this don't help.
Ultimately, I don't subscribe to his manifesto any more than I subscribe to manifestos about SQL being dead or monoliths being poison in all cases.
These things are all tools in the toolbox. You'll use some of them more than others during your career. You might use a given tool a lot because you like it, or you might use it a lot because it's a really useful tool even if you hate it. Both are fine. In addition, you'll find that sometimes you really /do/ need a triwing screwdriver, so it's nice to have that in your toolbox as well.
Don't be that guy who throws out either SQL /or/ NoSQL just because he likes the other thing or thinks it's more widely applicable. Both technologies suit some use cases the other doesn't. Use the tool that's right for the job, don't get culty about trying to wrangle an ill-fitting tool to a job it was never designed for just because you've tied your ego to it.
It's easy to forget the time and effort to accumulate the knowledge for fighting the limitations to a technology you've familiarized yourself with.
- A SOA approach requires less stack knowledge overhead and $$$ for actual deployment and use than monolithic applications.
NoSQL vs SQL? Not everything fits on a spreadsheet. Just because you've gotten good at wiggling things into one doesn't mean that you're right.
> Posted 4 times in twelve days.
Who is upvoting this?
I prefer NoSQL when there are scaling needs, because it _can_ scale horizontally. Sometimes it's just easier to use, too, and there are times when the feature set maps _much_ better onto the problem at hand.
Not all of your data access needs to scale horizontally, though, and if you have relational data you should use a relational database unless your scaling needs are extreme.
- "So I should only want to use vacuum tubes and Windows ME for my cutting-edge start-up? You call yourself a dev?!?!"
- "So I should update my legacy backend application every month with every twitter trend? You call yourself a dev?!?!"
I mean, the answer is painfully obvious: Start at the middleway and then move right or left depending on your scope, customers, budget and culture...
On the other extreme, the "React, SPA, SSR" people often discredit the page reload thing without thinking whether it works in the scenario.
I'm all for learning both ways, but don't like it when someone suggests something without objectively motivating why.
We're dealing with an interesting case where being the "shiny things that solve problems I don't want to deal with" person, we are struggling to get developers who can help our team.
We're doing some accounting software, and instead of the "boring software", we chose to:
1. Use Kotlin over Java
2. Use gRPC over REST
3. Use microservices over a monolith, or 3-tier whatnot
4. Use "containers" over "Java application containers".
Firstly; for the kind of gig we're doing, we've only been able to find developers experienced with Java EE, some who've mainly used Java 6 because some of the large shops are "that behind".
We got a software architect so that I could focus on other things, and he started off by wanting to tear everything apart, and move us to "boring software".
He's had some success, but slowed us down a lot in the process.
For example, he was uncomfortable with Docker or containers because in his mind, many clients still deploy GlassFish and JBoss/WildFly containers. So we were forced to get gRPC working on those application servers. He was unhappy with the idea of exposing ports (even internally) other than the standard 8080.
Then he didn't like that we were handling transactions manually, which was fine; so we moved to JPA. We implemented JPA with local resource transactions, and it was a mess trying to merge our Frankenstein with JTA transactions on the container. After we wasted a week, he conceded that we can keep local resource transactions.
He said that no client should consume RPC methods (he hadn't researched what gRPC 'solves'). So his suggestion was that we add a REST proxy on top of the gRPC endpoint that the front-end connects to. I tried explaining that the front-end already uses gRPC, but he insisted that the front-end would also have to proxy to JSON.
So, I explained that:
1. We have devs at varying levels, some beginner (because resource constraints), so Kotlin is easier than Java, to equalise the field. He was uncomfortable with mixing Kotlin with Java.
2. gRPC ensures that we have sane contracts between our services, making it easier to separate our offering into little modules. Imagine a client using SAP wanting to integrate our solution into SAP. Instead of modifying the guts, we can create a small service that connects to the API to do that.
I also personally wanted type-safety, and to not deal with errors like "the date format is incorrect" (which I dealt with during the prototyping days last year).
3. Microservices; we were able to abstract our database logic away from the business rules. Yes, JPA and Hibernate handle connecting to different database types, but we wanted further separation should we ever need to build with a different datastore (unlikely, but I built the prototype in 'Record Time (TM)' with MongoDB).
4. I had a Docker Compose script for the entire thing running in under an hour (incl. Docker build etc.). I had to step in on the ops side after a month of our JBoss thing still not working.
So, new and shiny tech often solves certain problems that we think don't exist, but until you use the tech, you won't realise that what your "boring software" was doing was less effecient.
Ask any developer who's written Java and earnestly learnt Kotlin. Ask anyone who used to deploy the "boring" way and now used containers. Ask any integration engineer who used to parse JSON and now uses Thrift or Proto.
Uncomfortable with Docker? Today? Or microservices? Or mixing Kotlin with Java?
I haven't used gRPC myself, but it looks like a strong standard. I have used Protocol Buffers in the past, though, and I certainly wouldn't be afraid of it just because I hadn't used it.
I've seen this kind of ultra-conservative outlook with Java developers fresh from enterprise jobs. Worked with one developer briefly who insisted that every new API would take at least two weeks of work. Even if the API was completely trivial CRUD. When I mentioned that I was using a framework that could stand up a new CRUD API in minutes, complete with authentication, validation, and user-based access protection, the developer called me a liar.
Which was funny because I'd just done _exactly that_ for another client, standing up the entire stack _and_ creating ~40 CRUD REST APIs (with parallel Socket.io APIs for real time updates) in about 8 hours. Adding or changing a model for one of the databases from that point forward just required a few lines of model specification code; additional custom code per-API was entirely optional. Of course I wasn't using Java Spring, so that may have been an unfair advantage, but there's a reason I don't use Java Spring...
I thought Spring is good. What's wrong with it?
I don't know the internal architecture, but given the poor benchmark results, I'd hazard a guess that Spring also functions as a thread-per-connection server, which means resource use would be very high for real-time applications (compared to Node.js or an event-based Java framework). And most applications today require at least a real-time component, so if you need 10x-50x as many application servers because you need an OS thread per concurrent connection, that's a huge additional cost.
 https://www.techempower.com/benchmarks/ -- Java and C++ tend to be the fastest in the benchmarks, but Spring is so slow that it hits between 2-16% of the top platform speeds, depending on benchmark.