> It replaced a site that was pretty much a home-grown PHP framework written by a single developer. Random mixed logic in templates, hard to update CSS and a poorly designed 'not-an-ORM' ORM.
Not to say that your rewrite is like that, but one man's garbage is another man's treasure.
But they won't be able to say it's not maintainable, upgradable, or scalable. And it's documented out the wazoo, all the way down to the CSS both in code and in the accompanying PDFs. The last developer gave zero thought to who would come next. I've given great thought, and included the occasional quotation in the code comments from Goethe where appropriate.
But if the company wants to pay him/her to blow away my work, then that's neither my business, nor my problem.
Saying software is clean because it is untangled from a larger code base is misleading for most use cases, but especially so for web development. It is also not fair to treat front end and backend code in the same context as you can easily decouple both without (since you didn't mention if the backend itself is custom built by you or not, but it seems implied)
People have been maintaining SW developed by 3rd parties for several decades. Something like 5 or 6, probably. With all the various amount of available documentation you can imagine, and that includes no documentation and really stupid code bases, or even no source code and you have to patch a binary.
So while I recognize it can be obviously cool to e.g. have virtually no code but simply use a well-designed and currently actively-maintained third party project, it is not always possible, and if it's not then implementing (or even just configuring) anything on top of fashionable software can also be done in crappy undocumented ways.
So the key is to actually have detailed and useful documentation, regardless of 3rd party stacks (or they very relative "absence", I mean probably don't develop your own web-server nor your own database nor your own programming language nor your own operating system nor your own web-browser...)
It depends way more on the organisation or team developing it than on the libraries you use.
You talk to one software engineer, and they'll say, "that's built in PHP, so it sucks; it should have been built with npm, obviously." Then you talk to another and they say, "I can't believe they built that with npm, the package management system is just terrible and the whole mess is bloated and there have been a ton of security issues. They should have used a static generator instead." And on, and on, and on.
Now compare this to a mature industry with real engineers who are able to say things like, "sure, that material might not be the most durable on the market, but unobtainium would have added $35 million to the project cost and ongoing maintenance costs would have gone up by another $5 million / year."
That right there is a comparison that developers can never, ever offer anyone that's writing the checks for a project. Nobody's bothered to do that work. We can't even accurately estimate the cost of a complex project given our choice of tools, let alone talk about costs and ROI with different toolchains for the same projects.
This is absolutely shameful IMO, and the reason why I cringe a little inside whenever I see the words "software engineer".
Also, those mature industries routinely overrun by millions of dollars and months or years, event though they are dealing with a fraction of the complexity and the costs and techniques are well known.
Software is the only industry where you are asked to build systems that have never been built before but that are more complex than anything ever built in the history of "mature industries", on top of astronomically complex systems, and estimate it with an accuracy of 5 to 10 days and a few thousand dollars.
What they do to the end user might be different, how the pieces come together, it is always the same, unless one is doing curriculum driven development.
Forget everything about responsiveness or whatever (which I find way more valuable than the tradeoffs one makes)--the lack of tight coupling is the real win of React and similar. I mean, if you'd like you can pretty easily build a server-side React app with NextJS and still get a lot of these benefits while using React purely as a pretty-dang-good templating language.
Old school server side rendered apps are underrated and its perfectly possible to make something that looks and behaves as well as a SPA app for most things.
Even in the case where you do have a specific frontend, I contend that there's still value in the separation because it very strongly encourages (coupled with tools like, shameless plug, nestjs-data-sec[0]) the writing of very clear viewmodels where thought must be put into what exactly should be exposed over the wire in a way that commingling database objects and template logic doesn't allow.
I think server-side rendered pages are properly rated at this point, not underrated; there are places to use them but they're shrinking as other tooling get better. As an example, even I write React almost exclusively because I write React faster and with fewer errors than any templating language I see in common use except maybe Razor (and Razor implies buying into ASP.NET, which, no). React/TypeScript are hard to get wrong and easy to burn through quickly. And I would call a React page rendered through NextJS a "server-side rendered app"--but I get the feeling you would not. ;)
You are seriously overestimating complexity and novelty of most software development, while underestimating engineering in other industries. I work currently as software developer and previously in a branch of a civil engineering.
Do you seriously think that other engineering disciplines to not have those small little problems that plague us all the time in software development? They do, but they can offer their solutions based on data, not just whim. They do also have codified standards, and guidelines and certification exams.
On the other hand software development is relatively new discipline - other fields had hundred of years to mature.
EDIT: and they are catching up with rapid prototyping - it is getting cheaper and faster.
I have a feeling that some SpaceX engineers would have something to say about this after one of their rockets lands on a floating barge.
That is because you are ignoring/left out the critical last part of the phrase you quoted: "and estimate it with an accuracy of 5 to 10 days and a few thousand dollars."
This is particularly relevant because this is a direct response to the following:
> We can't even accurately estimate the cost of a complex project given our choice of tools, let alone talk about costs and ROI with different toolchains for the same projects.
Anyone engineering hypersonic missiles would easily dispute that.[1] Or submarine-capable quantum communication systems.[2] [1]https://www.nytimes.com/2019/06/19/magazine/hypersonic-missi... [2]https://www.realcleardefense.com/2017/11/04/quantum_communic...
[1]https://www.scmp.com/news/world/russia-central-asia/article/...
But maybe its hard to admit it, lower down your ego and be a bit humble. Yes, software development is a creative work, but so are all other engineering branches. And yes, we have massive issues with code, process and people quality across whole business.
> That right there is a comparison that developers can never, ever offer anyone that's writing the checks for a project.
Sure they can. At Google there was an internal cheat sheet of "numbers every engineer should know" which included the cost in dollar terms of trading off engineer time vs. memory vs. CPU vs. network vs. user-perceived latency etc. (Actually there were two of them - the more famous one is the Jeff Dean version that traded off CPU cycles vs. L1-L3 cache misses vs. RAM latency vs. sending data over the network vs. compression vs. disk latency etc, measured in nanoseconds) If you had any moderately complex new system, you'd prototype a few different approaches on a small set of sampled data, do some multiplication to figure out how much it'll actually cost in production, then compare that against the engineer time needed for various optimizations. If you were in a revenue-generating area like Search, somebody (usually at the executive level) would also be calculating how much the project was likely to make or lose for the company and ensuring that's acceptable. Not all that unlike any traditional engineering field.
The thing is that the overhead for this process really only makes sense at Google scale. For the vast majority of new software projects, revenues on success >>> developer time >>> hardware cost. So you just assume that if you can get the job done in a way that satisfies the customer, it'll be wildly profitable, and the primary factor to optimize for is developer time. And if the developer can build it, the hardware costs needed to run it will be negligible, so just buy more hardware.
This is an artifact of the software industry essentially being a gold rush, where it's rapidly eating the rest of the world and replacing non-computerized processes that are millions of times slower. When you have 6 orders of magnitude to play with, you can play fast and loose with estimates, because any acceptable solution at all will make you a lot of money. When software has eaten the rest of the world and new systems are competing with existing computerized systems, then it's worth it to start paying attention to things like efficiency, security, TCO. There's some evidence we're approaching that point, but we're not there yet, and it's still more advisable for an entrepreneur to tackle an old-school non-computerized industry than to try and improve on existing software solutions.
Could someone alert Google's web developer teams (in particular the GMail frontend team) about that cheat sheet? If released products are considered as evidence, it doesn't seem like this cheat sheet is used.
[0] https://gcc.gnu.org/onlinedocs/gcc/Instrumentation-Options.h...
As well as having free-form pointers, C/C++ also have many, many dark corners.
What proportion of C++ programmers know that comparison = (c == c++); causes undefined behaviour?
> The thing is that the overhead for this process really only makes sense at Google scale.
The software industry is far larger than Google. If we want to claim that software is a discipline of engineering, we all need to have access to that kind of reference data, rather than trying to feel our way around in the dark in comment threads about blog posts about somebody's personal experiences.
I won't go so far as to say there's no such thing as software engineering -- a number of people working for companies with large budgets have well earned that title, I'm sure -- but the extent to which the term is traded like currency in our industry is disrespectful to the discipline.
> So you just assume that if you can get the job done in a way that satisfies the customer, it'll be wildly profitable, and the primary factor to optimize for is developer time.
The fetishization of developer time is one of the problems slowing the maturation of our industry. It ignores end-user time, it ignores management time; it often focuses solely on the initial development time of a project and ignores entirely the ongoing maintenance time for a project.
How many codebases are there out there that are gigantic balls of mud? How much developer time has been wasted on trying to maintain or refactor those codebases? How many really dumb security issues have negatively impacted companies or end users? How many comments has tptacek left on one little forum in one musty corner of the internet over the years trying to explain cryptographic and security-related best practices to an infinite legion of under-trained developers?
How many people have lost their lives to software defects? Not even the really tricky CS stuff, I mean the kind of defects that any other engineering discipline uses as case studies in their introductory courses.
Which case study would you choose for our Galloping Gertie?
Certainly software has done an incalculable amount of good in the world, and its impact is far and away net positive.
But while software has been busy "eating the world", it has rarely paused to also consider the cost and damage it has wrought and whether there are practices that could be standardized to reduce those negative effects. So I disagree wholeheartedly that we're not yet at the point that these things are important. Depending on who you ask, computer programming is between 60 and 180 years old. That's well long enough for us to begin asking questions like, "what data do we have to support this approach or that approach?"
There is still plenty of room for experimentation and research. There is still plenty of room for hobbyists and tinkerers. This isn't an exclusive-or thing.
As much as I really do appreciate blog posts like this one, and the discussion they tend to generate, and especially that there's a new one to read every single day (he said, wryly), I can't help but see every one of them as another indicator of the immaturity of our profession.
Part of this is because many systems are evolving, because business needs have human inputs and are not always "logical." At the edges where this human interaction happens, we expand the domain of programming to that of human psychology. There definitely are empirical claims we can make human-computer interfaces, but it begins to get a bit messy.
To be clear, I am personally interested in becoming more rigorous about empirically justifying claims I make about the code I write. But I’m also interested in code because many of the problems it attempts to solve map the very complexity of the real world. In many ways, abstraction is a properly philosophical exercise, and I think it’s impossible to separate a pure engineering discipline from this broader context.
Programming is multi-disciplinary, and I think that’s a strength.
We also have a multiplicity of building materials, tools, fabrication processes, etc. What's the standard way to make a steel object? Do you cast, forge, stamp, mill, sinter, roll, weld? I would expect engineering as a discipline to have more solid arguments for choosing which (combination) of those processes to use for a particular task than what is typically thrown around in discussions about choosing a programming language or paradigm.
The problem is that in many projects, especially small web-dev or simple automation projects, you simply don't know if they're going to be profitable. The margins are huge, since the upfront development cost is almost constant, you might lose $50,000, or you might make $500,000, or anything in-between, but you just don't really know beforehand. So obviously in this situation you want to become at least somewhat profitable as fast as possible, and then think about "doing things right" later. Is this horrible practice? Sure. But it's also the most logical thing to do here, because "doing things right" at the start is simply a huge risk that only pays off if you're successful anyway. And people would rather minimize losses than maximize gains.
On the other hand more traditional engineering tasks tend to require big up-front investments anyway, and "failing is not an option". I mean it really kind of isn't, if you need more money and/or more time you'll get that much more often here because the initial investment was so big already. So doing things right from the start makes complete sense.
Would love to see that. For companies determining what's worth what, this would be great to see, even just for the format.
1 engineer-hour =
W ms/search of latency
X GB-year of RAM
Y CPU-years of processing time
Z TB-year of hard disk space
etc.
I agree with most of your premise, but I think you overstate it a bit. Like the GP's point above, it seems like you're describing bad engineers. In the good web dev agencies I've worked at, they work pretty hard to make informed decisions which stay within budget and timeline. It doesn't always happen, but that's not just due to poor practice.
No industry can, unless it's something that has been done repeatedly before. If you ask a frontend designer specializing in WordPress to make a theme for WordPress and implement it, they can estimate it accurately.
What is thoroughly missing from this debate is the age old project management terms of scope and risks. As soon as you enter unknown land, the risk goes up. And risk means uncertainty and probably expenses. And if the people writing the checks change the scope, the original estimates goes out the window. If you're making a building, it's easier to understand that you cannot just change the scope after the blueprint is made. You have to get an architect to remake it, and everything done and ordered so far may or may not be salvageable. It happens in all industries, but just more so in software development.
they've been waaaaaaaaay longer than CS/SE
they do not change so robustly & fast in short peroids of time.
>We can't even accurately estimate the cost of a complex project given our choice of tools
Let's do not pretend as if that was limited to our industry.
There is still a lot of creative art and the more we stop pretending this isn't the case, the more people will be reasonable. There is still an high degree of technicality in the profession, but that doesn't mean its "engineering" -- you can be technical, not an engineer, and still respectable (heck, look at science in general). It's still a complex skill and makes lots of money for many businesses.
Not really, rapid prototyping - especially due to 3d printing - is a thing now - you can iterate on a model as fast as you can in CS/CE.
Also - a lot of engineering disciplines use simulations - civil engineering, avionics etc - so they too can iterate quickly.
We are absolutely horrible at estimating. I had article somewhere that analyzed plenty of CS/CE projects and found that we are good at estimating median, and if something goes wrong in most complex part - the time to delivery can skyrocket 100x.
Nah, this isn’t really true. Consider all the technology that came out of WW2: digital computers are contemporaneous with jet engines for example.
There are no shortcuts. You have to build a ton of software, and make a lot of mistakes, and most importantly, learn from them. Then there's the other half of the equation and some people just have the creative mind to imagine the right framework, or tool or library or abstraction or architecture for the problem at hand.
Our craft is very bad at providing such a canon. It is even anti-intellectual in parts ("what do you mean you cannot be a master after x weeks? You are a gatekeeper! you suck"). That and we are still not sure what is important and what isn't (i.e. what should be part of the canon). Our medium of study changes all the time. Arts medium of study is reality and reality, for all our advances, doesn't really change.
Maybe related, you were once considered an ignorant brut in this country and others if you haven't read a library of literary classics, now we have kids growing up who barely know Shakespeare, or the rich body of the writing of the abolitionists or slave narratives (how many people you think in this country that even know 1/100th of what Henry Louis Gates Jr knows?) Do you think W.E.B Du Bois and Booker T Washington are common names anymore? I remember when everyone had the preamble of the Constitution and the Gettysburg Address burned into their minds, now we can't be expected to remember questions for a simple AWS Certification Exam, it's pathetic.
I do not believe in the idea of a bimodal distribution of software development (not just programming) aptitude, but I sometimes wonder.
(Regardless, I don't call myself an engineer. Engineers get sued if their stuff doesn't work. I'm a software developer, no matter how good and careful I might be.)
A company/client will often make decisions based on "opinions" too. "We need a website, what should we use to make it?" It's a bit of a blank canvas situation at first where a developer/engineer could come in and say "We should do it X way with Y libraries because <some opinion on why it's the best stack>". Devs could have totally different takes on the same canvas by a matter of opinion.
If I were to ask people "What type of car should I buy?", I would likely get a whole variety of answers from hybrids to SUVs to European and Japanese cars based on who I asked and what their own preferences and tendencies are. I may end up happy or I may end up unhappy depending on which opinion I'm swayed by and how much rigor I put into investigating the different opinions.
Software can be very similar when people providing the "opinions" are caught up in looking to use specific tools over trying to figure out an appropriate solution. When developers/engineers/designers/managers immediate choose tools as a blanket solution over understanding the scope and use-case for context, it's a sign to heavily question the authority of their opinions.
There are a lot of dynamics going on. One is programmer's curiosity but then there is a financial incentive to be on the latest tech. If you see React jobs paying more than Angular jobs, it might be a sign to jump ship which has nothing to do with technical merits. Then there is things like Blockchain that excites investors and techies alike, even when it's a useless solution for something.
People sitting in a room deciding the genuine best thing to do is going to be hard with all these dynamics going on.
We've been building bridges for thousands of years, and still the relatively simple bridge they built down the road from me took 2.5 years to complete instead of the estimated 9-12 month.
I've seen non-science in Healthcare, and I've spoke out against it. I don't really understand why people are stubborn when there is data, and the data is solid.
If I could wish anything in software engineering- follow the data.
reaperducer's rewrite was an improvement, not because he replaced Javascript with PHP, but because he moved all the logic to the server, which is a single environment he controls. He could have used Node instead of PHP and achieved the same thing.
On the other side, when you render on the server, everything is already there. It's easy to write logic when the data you need is an sql query away and all you need to do is spit out some html. What gets a bit complex is keeping working state between pages and this usually requires handling sessions, cookies etc.
If you have a UI, you're going to have to manage UI state somewhere. Even if you have no client-side code, you've marshal that state into strings to send to the client, and then parse it all out again on the server when you get the next request. Remember hidden form fields? Heck, this very site has some pretty interesting history about attempts to solve that problem elegantly. It was a PITA.
Ultimately, none of that has to do with Javascript; it's inherent in a client-server architecture. The one thing that is specific to JS is asynchronicity. If you don't like that, ok, fair enough, but that's a matter of taste. It has advantages as well as disadvantages, and with Promises and async/await, it's actually pretty elegant. It's certainly not the case that asynchronicity makes you write shit code.
> Data being "an sql query away" on the server is similar to being "an AJAX call away" on the client.
This is a bit disingenuous, since sql calls in most back end languages are synchronous. Also an ajax call needs to update the UI to tell the user something is happening. This might mean disabling controls, showing spinners etc. All of this goes away if you only use server-side rendering since form requests are natively handled by the browser.
> It's certainly not the case that asynchronicity makes you write shit code.
But it expands the number of cases you have to deal in the UI, to show all the loading states, error states etc.
I developed my own custom scaffolding for Vue projects[0], which is a lot simpler and customizable. It even allows you to develop Vue projects without a build step/tool, you save and reload. Yes, there are tools that reload the page when you save, but I don't think they're worth the complexity.
It could be further improved to actually compile/build when you actually want to deploy, I hadn't the time or a strong need for it yet. But when you are developing, things need to be simple, I think you need to know everything that is happening in the browser so you can resolve any bug with much more speed and confidence.
Fundamentally, all of it is a matter of opinion. You have a million options and they are all correct. Don't take a million options at once, practice a lot, understand your problem domain. You won't write something perfect every time but you'll write something a whole lot better than if you were using a million frameworks instead of real thought.
In other words, "I can choose the correct tool but still fail from poor approach of problem."
Entire classes of bugs simply don't exist in better languages.
Trying to make web applications with it is another story though. The lack of any state management is a nightmare, hence declarative frameworks/libraries such as React/Angular(JS)/Vue/Svelte etc. etc. came along.
What makes the lack of state management a nightmare in the javascript world, but a complete non-issue when doing .NET or Qt apps?
As someone who started with desktop apps and then moved into web dev, I never really understood why Javascript developers wanted a library to help them manage state.
Meanwhile objects representing various parts of the view, and plenty of models that don't look much like "modern" JS state management, remain the norm elsewhere, and the sky is not falling. I do not know what to make of it. I go along with it when in that sort of company—when in Rome, and all that—but the evangelism can be pretty funny.
Anyway a bunch of the stuff isn't half as special as you'd think reading about it through the usual channels. Redux? A data cache and a so-so local event bus with somewhat awkward semantics and a few really bad terminology choices thrown in. Whee. There's your "state management". Not that it's useless, but you'd swear it's black magic reading all the blog posts about it.
The problem with javascript is that this concept is entirely lost on react developers. Due to the untyped nature of javascript and it's close linkage with html. HTML is made up of dependent components and this essentially puts dependency injection into javascript leading to JAVA like issues that the functional paradigm was suppose to solve.
The reason is rooted in how browsers work.
In native software you can "just" render your data structures directly to the screen. In the browser, barring webgl, you can't render your data structures directly to the screen, instead, you're forced to interact with an imperative browser API to individually manage bespoke UI widgets that store their own state internally and can't understand nor access any of the data structures defined for your business logic. The only option left is to manually update the internal state of the browser UI widgets whenever you update the internal state of your application. Manually keeping the two states in snyc is a real pain, highly bug prone, and a maintenance nightmare. The front-end browser frameworks came along as a way to "auto-sync" the business logic state with the browser ui state.
jQuery just changes the DOM. It gets very difficult to keep the DOM in sync with the JavaScript backed data when there’s multiple moving parts.
Again I don't understand this argument. What's difficult about it? People have been doing it with win forms for well over a decade now.
And yet it's recognized as a problem there, too, and one of the more recent solutions is state management libraries inspired by those used in Web apps, e.g., there are fairly direct copies/adaptations of React and Redux for .NET specifically to address this issue.
le sigh
*And you BETTER be using the minified version for production.
Good or bad depending on context.
Placing the blame on him when you were the one being hostile is hostile.
I think it should be a more widespread idea that people should aim to leave a company with a net-negative `cloc` contribution.
Every system that I've built so far has started out with a simple, obvious set of rules (both new systems and replacements for old systems). Then the customer/PM/whatever notices just one more edge case. And another. And another. And another. The truth is that reality is frustratingly complicated. Especially if the reality you're mapping contains the internal bureaucracies of large companies.
Erase existing software, so we have less amount of shit software.
I'm actually applying that technique at work with great results (really!)
I'm actually more found of when I don't even have to replace it: just delete the damn obsolete shit. Not replace. Delete. Most of the time it for cases where it is just dead. Sometimes it is only quasi-dead (from an incomplete previous modification) and in a few cases deleting it actually fixes some bugs.
The best patches only have - lines :D
The second thing is: companies do not only try to avoid existential threats; they also attempt to have economical approaches. If anything needs to be maintained, there is the potential, if it is crappy, to make maintenance costly.
It locks you, and future developers, into a paradigm. It might not be a "best" or even "good" way of doing things, but, adopting a framework helps keep everybody writing the same 'shit software'.
Consistency, it turns out, is key. That's because (as others have pointed out) all software is ultimately shit software. If you wrote it, chances are you don't think it's shit, but everyone else does.
That could be files or symbols in files that defined a set of operations a computer should run on symbols in another file/db.
This isn’t magic. But it’s susceptible to social behaviors and those are “growth every quarter, demand, demand!” so we latch onto buzzwords or trends because some VC funded dork thinks their way of laying out a todo app is best. IMO anyway.
Having gone freelancer and flipped the bird to corporate life, I’m way happier and write little code: not having to learn new frameworks makes when to write more generic, re-useable, dependency less, code way more obvious. And I don’t have to worry about a Github repo going inactive.
We’re making it harder with tent pool frameworks due to information overload. When the work is information organization, less is more.
A parallel to all that “more data is just a bigger security liability.” theme that popped up a couple years ago. It’s also a progress liability.
First, professional web app I developed 3 years ago is still being build upon now. Even though it is pure garbage and I hate touching it, because I "made it work". As I gained experience and got burned because I did something a certain way I slowly but surely looked for alternative approaches.
Now 3 years later, I'm building an app with layered architecture, proper separation of concerns, dependency injection. Plus, before I start hammering code away, I think about what is the number 1 priority for a piece of code, am I gonna use it once and forget it? Will I use it all the time? Then, proceed accordingly.
I think about what is the number 1 priority for a piece of code, am I gonna use it once and forget it? Will I use it all the time?
Overbuilding the initial version of something for a bunch of anticipated (rather than actual use/failure scenarios) is something I now work very hard to avoid.
The key IMHO is really being nimble enough to extract and/or refactor and/or refine as soon as it is needed. Not before, not after.
"Overly robust" code is actually a huge problem sometimes. All that unused code is in there, giving the appearance of being robust, but is not actually battle-tested....
Isn't the saying, YAGNI (You're not gonna need it)?
(Aside, flip the contraction to get the acronym - "you aren't gonna need it")
Shifting project and business requirements, scope creep, poor design choices and lack of competence all contribute to what makes bad software.
The point of (well-designed) frameworks is that they act as “rails” and make it difficult to make bad decisions.
They also make it easier for people on a team (or people who maintain the project after you leave) reason about your code.
Therefore, as far as I’m concerned, not using frameworks is a huge red flag.
edit: bring on the downvotes!
I took a look at the code on GitHub and it was absolutely horrible. They basically built their own mini-framework, poorly, with mixed concerns and poor, ad-hoc and inconsistent validation everywhere. Terrible.
I left an issue on GitHub with my findings and got into an argument with the author in the HN submission about how it's disingenous to say something is engineered from the ground up to be secure, if you're eschewing all the man hours that have gone into something like Larvel. I think his reasoning boiled down to "Larvel has CVE's so it's not secure".
Some people are just like that I guess.
Edit: found it - "How We Engineered CMS Airship to Be Simply Secure" https://news.ycombinator.com/item?id=13905055
It could be a signal of sloppyness or writing it in vim.
> This is not engineering a project to be "simply secure", in the sense that it is definitely not simple and probably not secure!
Messy, duplicated code that re-invents the wheel hides security bugs.
Saying "Windows has security issues, so I'm going to write my own operating system for my software" doesn't mean you can't knock it out of the park and make the most secure operating system ever... but I wouldn't exactly bet on that being the case.
The answer is obvious in both cases; You don't need it and it would be wasteful. If I don't have a huge database with constant read/write calls, If I don't have to try to manage multiple end users submitting content, if I don't need super async real-time snappy UIs to compete with the latest android app fad or session tracking of tens of thousands of users, why would I need laravel?
If nobody rolled their own specifically for what they needed, we would still be writing ASM/APL/Raw hex.
In most cases you can buy a modestly sized vehicle from a manufacturer that still has a team of people ensuring the performance, utility, and safety of the vehicle.
It's like, outdated Wordpress sites get hacked all the time, but if I just threw together my own shitty blog in PHP and MySQL there's almost no chance it would, as no one (generally) is going to take the time to figure out hacks for just one site (especially for SMB).
You can always import libraries into your project for the critical stuff, instead of using the whole framework.
Even Laravel itself imports third-party libraries such as Symfony, which you can use in your project without importing Laravel.
"After me cometh a Builder. Tell him I too have known."
Not entirely related, but there is usually the incentive to at least say this for a new person/team coming on because money. Especially for frontends, the new person/team we talk to when going into an existing project, says that it has to be redone because it's 'not up to standards'. That is not because it's not fine and maybe even beautiful; it makes more money to rewrite it. And job security perhaps too. So when someone says something is garbage, I need to assess the reason why; is it garbage or does the person saying it benefit from a rewrite somehow.
To be fair the parent comment isn’t saying everything about his stack is perfectly elegant, but if you can deliver a website that works without stateful client side JS and associated build tooling, then it certainly is simpler, and most of the time simpler is better.
Simple cgi endpoints and static files for any css/js should be our starting point and any web developer should understand them. When the problem becomes bigger and more complex is when we should start looking at frameworks.
When was the last time you had a go at CSS? So much has changed since 2017. You can chuck out the pre-processor junk and just use CSS variables and CSS Grid. Productivity is 10x.
You can even keep it simple so that a page just loads the CSS it needs instead of some 40,000 line ball of junk.
Same with templates, if you are using CSS Grid you don't need the sea of div containers, you can just use actual content elements from HTML5 and never use a div.
Pseudo-selectors mean you don't need spans. You can get pretty things done without the markup in the document. Once you write HTML this way you wonder what on earth people are doing with these impossible toolchain and impossible HTML web pages. Regular development from about five years ago with frameworks and jQuery nonsense just looks like hacks.
Also add a banner at the top telling people they need to use their other browser for the page.
What business are you in where 8% are still on IE11?
You can try the polyfill approach. This is generally not recommended as it wastes bandwidth. But since your customers have bandwidth you could go with polyfills. Or just stay stuck in the past with a niche of writing IE11 compatible stuff. That could be career limiting, IE11 is getting as irrelevant as 8.3 FAT filenames.
https://en.wikipedia.org/wiki/Microsoft_Edge
Edge is supposedly an option even back to Windows 7, though I don't believe it's a required security update. I haven't used a Windows 7 system in long enough that I'm not sure.
At this point it is reasonable to tell people they NEED to install a more modern (and more security up to date!) web browser, be it Google Chrome, Microsoft Edge, or Mozilla Firefox.
Many government and healthcare organizations STILL using Internet Exploder, presumably until its 2025 end of life:-(
As far as I know, Microsoft plans to keep IE11 around as long as Windows exists.
Oh you sweet summer child...
PS - this “child” started working as a developer, at least part time, back in 1985
C++ eventually passed into a bad memory, and so will MSIE.
And the hiring manager who can’t find anyone that doesn’t want to pad their resume for the same reason.
It's easy to build a simple website with no frills that does exactly what the client needs -- if you know how to do it. Even then, it is rarely easy to figure out what the client needs!
A colleague wanted to use a Javascript library for something I thought was probably pretty simple. I suggested we take a look at the library and see what it was doing and determine if it was worth the extra dependency. He joked, "If I wanted to know how it worked, I wouldn't have chosen a dependency". Luckily, it's not how my colleague really feels, but this is exactly what's happening most of the time.
Things are over complicated because people don't know how to build them -- they glue together a patchwork of stuff so that they don't have to know. In the end, they tend to build something whose complexity is many orders of magnitude higher than the complexity of the problem they are working on.
Your two years of job security was not for avoiding framework-of-the-day hype: it was for knowing how to do it. It's the simple 30 second, single line sketch that captures the picture perfectly with no extra complexity. That takes years and years of experience to develop -- and a desire to even get there at all.
Point is that SSR (Server-Side Rendering), with a sprinkling of simple JavaScript and XHR calls as required, is enough for almost everything I do, and it means build are really simple. Doubly so with a strongly typed language like C#.
I've worked on Angular and Vue projects, and the complexity level was (subjectively) much higher, despite these particular web apps not requiring any real level of client-side functionality. I find JS tests to be much more complex and brittle than C# ones too. Honestly, I hated it! Now, some of this was undoubtedly because I'm more comfortable with what I know, but certainly not all of it.
A frontend framework is great if you are a company that really needs to slim down bandwidth and can hire expensive devs to maintain it. But for a simple no nonsense business application it’ll just slow you down and will gravitate towards being a mess.
TBH, I'm not all that keen, possibly because it reminds me of the bad old days of webforms with code-behind files. Maybe I should try it in anger before I judge it though :)
I completely agree with all of this. There is probably a billion-dollar market out there for rewriting garbage business apps that were developed using the hipster tech flavor of the week.
BUT, i don't think this "crude design" trend will ever have the same attractiveness to junior developers no matter how much hype it gets here. Being attracted to "new shiny things" is very intrinsic to human behavior, and tech companies will keep spending ads to sell their new tech to the market.
I’m not sure ActiveX, ASP, and SQL server were ever hipster. You’d be doing the world a favour by re-writing these apps.
Literally doing a favour: there’s never any budget for it.
Think it will look as maintainable as it is today?
Or do you think a new consultant will roll through and easily sell the client on another rewrite-from-scratch project?
Yes, and it takes less than a second (checked in Chrome performance console) to do it. I'm happy with that.
Also hacker News is one of the simplest use cases ever.
Note that 95% of Facebook by usage (scrolling through feed, liking and commenting) doesn't have much more functionality than HN.
But it could have very easily gone the other way. If your website had complicated validation rules on multi-page forms (not unheard of in healthcare) the site would be better off for some basic state management interacting with a standardized authentication/authorization framework that you didn't have to write.
From what you're describing, it sounds like you did right by the client in this circumstance. But sometimes, it does have to be complicated. And in those circumstances, frameworks and javascript (unlike garbage) have an important place.
It almost never has to be complicated. People just enjoy making it so.
Looks at their inventory management system
jQuery would fit well here.
onSomethingChanged() {
$('#foo').prop('disabled', true);
$('#spinner').removeClass('invisible');
$('#error-1').prop('hidden', true);
$('.buttons').hide();
if (value) {
$('#btn-2').show();
} else {
$('#btn-2').hide();
$('#btn-3').show();
}
// etc ...
}Round trips are just fine. Browsers are smart, servers are fast, and HTML compresses well. The site you're reading right now (HN) requires a reload. Stackoverflow requires a reload. Neither are slow to use.
If your page is really that complicated, then I suggest Vue or Preact which are efficient and designed to progressively enhance pages instead of rebuilding everything in JS.
Sites like HN and Stackoverflow have a vastly different audience than most bread-and-butter sites, and tackle different kind of issues.
If you really need a offline site then a simple service worker is all you need to cache the pages, not a big JS app.
You can write bad apps in any language and environment, similarly a site/app is not bad just because it's done in Y.
I would like to trade out AngularJS for Vue someday, though.
1. Render model from your JS object.
2. attach events
3. Change model
4. Go to step 1
However I would be concerned about a couple of things if this were me and I was doing anything beyond the absolute most basic web app:
- long term maintenance. Doing something only you understand and only you can maintain (that job security you mention) is a bit of an unprofessional dick move IMO.
- if you need to get other people in to help, you now have to spend more time training then up on your custom system that they don't understand and keep an eye on them to make sure they are doing it right and not introducing security issues
- When your client wants to integrate with some common third party thing ("hey can we put Google maps in here?"/"we need to integrate with stripe payments") you'll need to reinvent the wheel from scratch to do it using your custom system rather than just use a well-supported off the shelf library.
- you'll need to stay 100% up to date on all security issues/approaches/classes of vulnerability to make sure your custom system is secure. Your audit was ok this time, but everytime you make a change to your custom library (e.g. to support Google maps or stripe) you're now going to need to go through the audits again to be sure you've not opened up any new security holes (and perhaps new ones you've not ever heard of because you are only working in this weird little custom system/thiefdom for the past 2 years)
- how to support the INEVITABLE requests for extra features that require something client-side that cannot be easily done with only PHP and static pages. It is not the 90s any more - the cat is out of the bag regarding interactivity ... the requests for client-side nicities that users are used to in other things WILL COME! Clients always want more! :-)
Still anyway I guess you don't need my good luck wishes as I am sure you are correct and that you really have out-thought and out-coded all of the well-supported and well-funded frameworks that have been built by many thousands of people and have been battle-tested in the field for years (e.g. Laravel, .net MVC, struts etc). Because otherwise if you hadn't totally out-smarted the entire industry, I'd be shitting myself and checking my professional liability insurance about now.
A decently structured PHP application is often maintained by nontechnical people with a limited understanding of programming but they can get by with just a text editor and a codebase. I have not come across any nontechnical person who could easily get a react/modern js framework pipeline going to do a small change, not to mention dealing with npm changes. I would almost feel like it would be a jerk move to leave someone without a technical department a pile of react/npm soup right now.
There's nothing in his post suggesting that the way he developed is harder for someone else to pick it up. MVC Frameworks aren't necessarily easier to use than vanilla PHP. Your answer reminds me of people who don't know how to use vanilla JavaScript and have to add jQuery to the project for things that could be one-liners in vanilla JS.
The whole "what if the customer needs something in the future" is just a piss-poor excuse that bad developers make to prematurely optimize. There's nothing in an MVC framework that makes it easier to add new features.
There is nothing preventing him from using official libraries for Stripe or Google Maps if needed.
There is nothing preventing him from using libraries that can be updated, probably with a single CLI command.
There is nothing suggesting his system is unsafe. Quite the contrary.
He didn't outsmart the entire industry. He just built something that works without relying on your favorite tool. Maybe you should try someday, you might actually learn something.
A simple php endpoint is something any web developer can understand. The more frameworks/libraries/patterns/abstractions you throw in the less likely it is they will understand it. Especially years later when the framework is inevitably out of date, good luck convincing why they need to spend money upgrading a framework every year.
> hey can we put Google maps in here?
Has this changed recently? Last I checked you would just drop a script tag into the page, who needs a library for that? Edit - I checked (https://developers.google.com/maps/documentation/embed/guide), how does a framework make a copy/paste job any simpler?
> "we need to integrate with stripe payments"
I'm not familiar with stripe, but don't you just give it a return url? I don't see how a framework would help at all here.
> you'll need to stay 100% up to date on all security issues/approaches/classes of vulnerability to make sure your custom system is secure.
This is harder with a framework, it's one more thing to keep updated. The less libraries the less vulnerabilities.
Having worked with both kinds of application, I personally find it much easier to learn my way around and understand a self-contained application than one which is a giant web of moving-target third party dependencies and frameworks, themselves largely undocumented and subject to the framework-hipster "move fast and break your users' things" mentality.
Agreed in general, but there are better free/libre choices. I don't recommend these for greenfield projects.
I'd replace PHP with practically anything written by grownups. (Django, Rails, etc.)
I have been much happier professionally since that day.
But other than e-commerce, yes, Django or even Rails is my preferred choice.
And both probably beat out Node.js
In most of my personal projects I've been following this approach too, and I must say, I'm so much more productive. I don't find myself constantly switching between browser-, terminal and VS Code-windows. I don't have to do validation twice anymore, and know perfectly where all my data is coming from.
MVC PHP frameworks are very nice and they don't move as fast as those javascript frontend rendering.
Also the ORM deals with any security problems and most framework deals with other security deals too including session handling.
It takes a massive amount of resources to develop your own security, your own data access without any ORM tools, not cause memory leaks, properly disposing of resource.
I'm all about creating reliable applications, but a good framework is a great tool.
Just because the framework uses them by default it doesn't mean they can't be used separately.
You can use Razor Pages or a router like Nancy[1] without having to roll your own ORM or View Library.
It's php. Everything is trashed once the http request has been served.
I think it's way nicer. I much prefer environments like Sinatra, Express or Flask than full-blown MVC frameworks.
There were so many ways of structuring your codes. I find myself constantly rewriting the code to adapt to a new way of organizing codes.
I personally prefer a somewhat opinionated framework.
But I understand that there is a pro and con and a need for a barebone/slim framework versus a featureful framework.
I actually moved from flask & vuejs 2 from last year to phoenix & jquery.
- PHP: A few years ago I heard about how PHP was needlessly complex. I wonder what the recent status of the programming language is. Specifically, do experienced PHP programmers stick to a subset of PHP, as in "PHP: The good parts"? (similar to "Javascript: The good parts"). (side note: As a diehard python person frustrated due to latest versions becoming bloated in features, I fully acknowledge that I'm in the "Python: The good parts" camp right now).
- MySQL is owned by a company lately. I wonder if PostgresQL is clearly a better alternative?
See: https://phptherightway.com
Modern PHP development comes in the form of loading dependencies from Composer/Packagist, rather than offloading a lot of bloat to the language. Lots of things have been deprecated (and even removed, like ext/mcrypt).
Some of the defaults like globals being turned on by default led to security holes. How people were creating sql statements at the time concating strings led to sql injection issues.
There were never any bad parts . There are new features like the spread operator that are newer and not available in earlier versions. I try to stay away from them if I think the application will need to run on older versions but otherwise I feel like I can use any feature.
Postgres needs to run under a specific os user. That alone makes it a poor MySQL replacement
I have also written heavy amounts of Python and Java at various points in my career. A few other languages too.
PHP has many, many bad spots. It's easily the ugliest, clumsiest language I have been paid to use.
It's slightly dated, but this is still the best summary I know of:
There where, and continue to be, large numbers of bad parts. Magic methods that do random things in certain cases, terribly defined interfaces (array_search), ridiculous typing, an impossibly incoherent standard library, etc.
Where did you get that idea? Postgres can run as any user.
In fact, I recently switched my applications to use Postgres even during unit tests (instead of SQLite), i.e. that testing instance runs under my normal login user. That change actually made the CI go faster because compiling the Go SQLite driver takes much much longer (about 30-60 seconds) than spinning up a Postgres from scratch in a temp directory (about 2 seconds) and using that instead.
@fizixer: I don't use MySQL, but I've heard it's not nearly as bad as it once was. I use PostgreSQL for everything from traditional relational data to time series to job queues and am 100% satisfied. Hasn't once let me down. The only caveat is that clustering is still easier to do with MySQL than with Postgres from what I hear, so if you have really really big setups that require that, that should be considered.
MySQL 5.7+ is decent. Where it loses out to PostgreSQL is the lack of plugins/extensions. PostgreSQL is extensible in ways MySQL users can only dream of (e.g. timescaledb, pg_trgm)
Also, the forking of MySQL and MariaDB has resulted in 2 very similar databases that people consider interchangeable - but aren't. There's plenty of "gotchas" if SQL is meant to run on both.
It has different philosophy, and needs a little getting used to, so it's not as easy as simply lift-and-shift
There certainly are some types of apps that are mind-bogglingly complex (e.g. press play and scroll around on https://kepler.gl/demo/nyctrips for one vivid example) but ironically, the real heavy lifting is mostly done with specialized libraries and super-close-to-the-metal code (GSLS), whereas the "modern" stack only powers the "simple" boxy UI glue stuff.
Also, if I were a team lead, I definitely wouldn’t have chosen that stack because it’s harder to recruit career driven developers who don’t want to work on tech that doesn’t help then build their resume.
When it’s time to land the next job, using $cool_kids_stack of the day, you will be at a disadvantage.
For context, when it comes to modern front end development, I’m barely above “not eat the chalk” level of competence so this is definitely not meant as a technical critique.
Any reason they liked it in particular? Faster? Better/cleaner UI?
Their old sites were weighed down with an incredible amount of confusing technology.
I redid the whole thing with PHP/HTML/CSS/JS/MySQL as well, and it's incredibly easy for them to update and work with now. Super simple admin interface, attractive front-end, and the top brass at the company has taken notice.
This is my problem at the moment. I have a nice static site, but I'm facing demands from the marketing team to use Wordpress so that they can make copy changes to the site without having to go through a developer (or learn any HTML).
I'm not sure why you need a modern "looking" site since JS is about the functionality not the looks.
The funniest comment I have read on this website.
Wait, PHP is not garbage?
I used to code in ASP and PHP back in the day, and that approach made a lot of sense. You'd have things that run on the server, and then those things throw out a website for the user to interact. If there's a need for reactivity, use some JS, but basically it all goes back to the same server program. I always found that this approach was good enough. You could do a lot, heck, I even wrote a browser game back in the day. Most importantly, it was simple, and it led to great web pages that would always work and could be used as such. No JS, no cookies? No issue, your code would just deal with it. A button was a button, and link was a link, and your browser did the rest. Text got sent as html, pictures were loaded or not depending on your preferences. Everything got faster and faster. This was years ago.
In the meantime, I stopped doing web dev.
Suddenly, in the last ten years or so, I noticed that websites became bad. The whole web just seemed to regress. Everything was JS, everything became single page, and if you didn't enable every single function in your browser, or if you pressed the "back" button, or reloaded the page - basically if you did not pretend that the website's UI was an actual native program - then everything breaks. News sites stopped loading text or images halfway through, buttons stopped working. Links were not clickable. Pictures would not show up. LOADING bars and circle-things appeared on websites that were already downloaded on my computer. Registration forms did not load default options, choice elements were empty. Once the page was loaded, everything was sloooooow. Scrolling became "different" and often laggy. Websites would load, then do something in the background to reload into garbled messes. Printing didn't work correctly. It's like Flash websites of my day (that everyone know were terrible and had very few good use cases) became the norm, but without Flash.
What happened to the internet? Why is everything garbage? Did all web developers die out?
I went back to make a simple website for myself. Reading tutorials, it was clear I had to use some framework. It was recommended to use JS, install some sort of server application and database, then a framework on top of that, and then something that runs in the user's browser. But everything was its own programming language, with no common denominator. You'd either need a PhD in JS and server development, or be happy to buy in to some framework that was usually not even very good. I did not understand anymore how web development works. I did no longer understand how the websites came to my customer, what the server did, how and when it did it... and everything was hard, even though this should all be really simple. And what came out was just... bad.
I went back to using simple web dev tools if I need to, and thought "well my needs are just not so advanced". But given that most websites have become so terrible, I just can't help but feel it all went wrong. Whoever thought up this frameworks and JS revolution was probably really smart, and there are probably some really good websites out there.
But I hate the internet now, and I don't understand web development anymore. I'm not even that old.
I'm really glad to see that this no nonsense approach catches on.
I've seen comments like this on HN and then I've seen these types of applications in the wild. I call it the most dishonest form of consulting you can do. You've put a real shine on some inflexible shit and the clients obviously have no way of knowing what they've bought into.
>It replaced a site that was a mess of javascript libraries on top of frameworks on top of a half dozen jquery version and on and on and on.
These people are incapable of correctly evaluating work they contract out, or who is doing it. Why do you think you're an exception in this case?
If I'm the next developer I would thank him.
Ever deal with 5 versions of jQuery that are conflicting. Trust me life is easier in vanilla php.
Consolidating versions of jQuery.
>If I'm the next developer I would thank him.
For what? You wouldn't know anything about the previous site implementation
Popular frameworks are not silver bullets, but apparently it's popular on HN to think so.
Also I'm 97% sure I could own your site in under a day, based on how home-baked you just said it is, and I'm garbage at pen testing.
Healthcare site, you say? Jesus Christ, I hope they have data breach insurance.
Thats from someone who does that for a living.
Modern web-devs move faster than they think, leaving so many doors open. Someone who works on the same system plenty of years had time to patch the doors.
But am I not right to have red flags fly when someone says they built a home-baked web service for managing health care information? Isn't that nuts, from a security perspective?
SQL escaping, session handling, etc all come easily with standard php libraries. So "I didn't bother with any PHP frameworks" doesn't mean the dev wrote an SQL connector.
There are a hundred examples that are specific to whatever app this guy built for the Healthcare company, not all of which are covered by the PHP standard library...
I believe him when he says it passed external/internal auditing, however I have a very hard time believing he's not either very very expensive or took a very very long time to get the app to the place he claims it is (the third option is that it does very little, which won't actually end up being a good thing once the client gets over the honeymoon phase of "it's so much prettier!!!").
Further, the expertise I do bring to this conversation is in software development, and I can say assuredly that a one-man development team using no 3rd party libraries is definitely creating a codebase nigh unmaintainable by other people down the line. His bragging about creating job security for 2 years is honestly an understatement; he's got job security for the life of the products he's creating, as he's likely the only person who can do anything more with the website in a time frame that isn't measured in years.
https://www.php.net/manual/en/password.installation.php
"There is no installation needed to use these functions; they are part of the PHP core."
The functions are common knowledge in the community, and made to be easy to use.
> Further, the expertise I do bring to this conversation is in software development, and I can say assuredly that a one-man development team using no 3rd party libraries is definitely creating a codebase nigh unmaintainable by other people down the line.
They said, "No frameworks." They didn't say no libraries. Some people make a distinction between the two, others don't. You are taking the stance that they mean they mean the same thing. Realize that others don't consider them the same thing.
Further, the expertise I do bring to this conversation is in software development, and I can say assuredly that someone who doesn't know the nuances between libraries and frameworks in the software development world can't make the claim to have expertise in the software development world. =)
I think it is, especially since you are nitpicking on it. I'll explain.
If the original poster is using libraries but not frameworks, and feel there is a distinction (and judging by the post, it's clear they feel that way), then they are using libraries, just not frameworks.
Therefore, when you say this: "a one-man development team using no 3rd party libraries" in the context of the discussion, you are making stuff up. No where does the original post suggest or otherwise say that they aren't using 3rd party libraries (quite the opposite).
For your comment to hold up, you need framework and libraries to be the same. However, by pointing out that often times developers see them as different (generally libraries make up frameworks), I'm making it clear that your conclusion is misinformed.
> I'm pretty sure that your failure to address the "this is but one of hundreds of examples, not all of which are covered by standard libraries in PHP" comment I made is further justification of that belief.
I addressed directly the one example you provided. You didn't provide hundreds. You provided one. I provided the answer out of courtesy, as you asked a direction question. Saying answering your direct question is justification of my dishonesty is insulting and childish.
Further, the fact that you are mistaken on the concept of the common use of library vs framework, I felt that your claim of "hundreds of examples" was hyperbole and ignorance. Maybe you can provide hundreds of examples where PHP and libraries written in PHP cannot solve problems that only fully fledged frameworks can provide? Keep in mind that libraries exist for many different things and since frameworks are made up of libraries, there is almost nothing relevant that a framework can do that libraries can't.
It does, actually: https://www.php.net/manual/en/intro.password.php
You would need to implement whatever custom code required or use a libruary. You would need to do the same with a framework. No framework offers business health care functionality. Do you think laravel has an ocr skin cancer detector package?
PHP is fast to write. Hearing people from the outside saying its impossible to write a php site that quickly makes me laugh. PHP makes development easy.
Yeah that's odd to me too. I mean, that's pretty much the biggest argument against using PHP (well it was, back in the day). Bad sites written easily by inexperienced programmers.
A lot of bad software engineering going on in these comments, downvotes don't change that...
The internal and external security audits already performed by the billion-dollar healthcare company in question disagree with you.
If it's simple enough and they understand PHP well, it could easily be better.
Accessibility Cross browser polyfills Easy translation support Automatic mobile view Developer mindshare
The lack of polyfills is VERY concerning. Your site probably doesn't work on 10% of browsers. And getting from 90-99% is an excercise in futility.
If you used a popular UI framework and transpilation you could easily write a super modern site that works on practically everything back to IE6. And with Vue or React the whole thing could be a few hundred KB, probably smaller than some of your images.
If I was brought in to work on your site, I would immediately rewrite it if it's more than a few pages. Plain HTML with PHP becomes an unmaintainable rats nest if you try to do anything complicated.
First of all, "job security" means that you're irreplaceable, and in the case of you actually being the architect/designer, that probably means you did a (perhaps intentionally) bad job to make yourself the linchpin. Not good.
Secondly, regardless of the first point, programming is hard. Anyone that says otherwise should be avoided like the plague. It's beyond the scope of one individual to be able to keep up to date to all the security issues and gotchas prevalent in a language or ecosystem. This is why you use frameworks. They're democratic units that within themselves handle patches and development in ways that are often better than one "irreplaceable" developer on a unique object (of course, bad developers can still use frameworks and derail the product completely to the point where all benefits of the framework are negated, but that's beside the point).
A few weeks ago I launched a new web site for a health care company. HTML, PHP, CSS, and MySQL. No frameworks. No javascript. No garbage.
It replaced a site that was a mess of javascript libraries on top of frameworks on top of a half dozen jquery version and on and on and on.
The company administrators, doctors, practitioners, etc... are so happy with the new no-nonsense site that they raved to the parent company about it. The parent company's IT department looked into the site, asked me some questions about it, and yesterday I was been asked to do the same type of cruft-free rebuild of three other sites that the company owns.
Not buying into the framework-of-the-day hype just landed me job security for the next two years.