I think practically all “Why You Should…” articles would be improved if they became “When You Should…” articles with corresponding change of perspective.
An even better formulation would be “Here is the source code for an app where I didn’t use a framework. It has users, and here are my observations on building and deploying it”.
In other words, “skin in the game” (see Taleb). I basically ignore everyone’s “advice” and instead look at what they do, not what they say. I didn’t see this author relate his or her own experience.
The problem with “when you should” is that the author is not in the same situation as his audience. There are so many different programming situations you can be in, with different constraints, and path dependence. Just tell people what you did and they can decide whether it applies to them. I think I basically follow that with http://www.oilshell.org/ – I am telling people what I did and not attempting to give advice.
(BTW I am sympathetic to no framework – I use my own little XHR wrapper and raw JS, and my own minimal wrapper over WSGI and Python. But yes it takes forever to get things done!)
His earlier books are also good. It is a lot of explaining the same ideas in many different ways, but I find that the ideas need awhile to sink in, so that’s useful.
He talks about people thinking/saying one thing, but then acting like they believe its opposite. I find that to be painfully true, and it also applies to his books. You could agree with him in theory, but unless you change your behavior then you might not have gotten the point :-)
Less abstractly, the worst manager I ever had violated the “skin in the game” rule. He tried to dictate the technology used in a small project I was doing, based on conversations with his peers. That technology was unstable and inappropriate for the task.
He didn’t have to write the code, so he didn’t care. I was the one who had to write the code, so I’m the one with skin in the game, so I should make the technology choices. I did what he asked and left the team, but what he asked is not what the person taking over wanted I’m sure.
In software, I think you can explain a lot of things by “who has to maintain the code” (who has skin in the game). I think it explains why the best companies maintain long term software engineering staff, instead of farming it out. If you try to contract out your work, those people may do a shitty job because they might only be there for a short period. (Maybe think of the healthcare.gov debacle – none of the engineers really had skin in the game.)
It also explains why open source code can often be higher quality, and why it lasts 30+ years in many cases. If the original designer plans on maintaining his or her code for many years, then that code will probably be maintainable by others too.
It also explains why “software architect” is a bad idea and never worked. (That is, a person who designs software but doesn’t implement it.)
I’m sure these principles existed under different names before, and are somewhat common sense. But they do seem to be violated over and over, so I like to have a phrase to call people on their BS. :-)
Yeah, the phrase works as a good lens and reminder. Interestingly, as most parents will attest to - the “do as I say not as I do” is generally unsuccessful with kids. They are more likely to emulate than listen.
IMHO this article could have done a much better job of saying “don’t blindly trust the framework but also think about how things work underneath”.
I do get the point that the author is trying to convey. But unfortunately the language that’s used and the tone in which it’s conveyed makes the advice come off wrong-ish.
I agree. At first, when I read the title, I thought “ohh.. We’re just going to disagree on this one…”. I had to maintain countless Python application just doing SQL/CRUD and the previous engineer either glued Flask and SQLAlchemy together in a bad way, or worse invented their own framework based on WSGI. And every-time, I just migrated it to Django with half to a tenth of the original lines of codes.
Then, I read the article, and all it says is “please understand how frameworks work under the hood”. Which I totally agree with, and that’s what I always teach juniors when I train them with Django or Flask.
I have been at a few companies who have decided to do this while I was there. I have also joined a number of companies like this after the direction has already been taken. People need to realize what decisions they are making, and think about the future more often. This is almost always not the right call.
You get rid of frameworks and your team learns the fundamentals. This is undeniable value. Knowing how the clock ticks is important when it’s your job to make the clock better. Frameworks should never be an excuse to not learn these things.
You get to a point where you know the basics. Great.
Everything is easy because you don’t need to know any abstractions. It’s dope.
Now you find patterns that are being used over and over again, so you create thin abstractions for them. Awesome!
Soon, you have abstractions to make your abstractions easier to work with in niche cases, and they’re amazing!
Some abstractions become useful elsewhere, end up representing an unreasonable percentange of code, etc.
You make them into separate modules, and now all of your code looks so clean. So great!
…Oh, damn! It looks like this is the “I Have NIHS and Want to Build My Own Framework With Less Commuity Support Manifesto”.
I highly recommend avoiding this story. It sounds so easy, but it is hard. Small things become big things. Big things become bigger things. So many things become SO MANY THINGS. Nobody outside of your company knows wtf your thing is, because there isn’t a community fostering it.
You probably won’t believe me now, but when someone can recreate your 2-year-old startup from scratch with higher quality code in 3 months because they were smart enough to choose the right tools while you were off in play land inventing your own, you’ll realize this. It’s a huge time sink that is easy to avoid when you’re only seeing the day-to-day and not focused on the month-to-month.
Its not that nobody knows how this stuff works when they use a web framework, its just that nobody wants to invest the time to make the same mistakes as other when it comes to edge cases and the like.
I dont know how this article is aimed at, but for someone who knows how this stuff works it’d be a PITA to rewrite everything from scratch for no good reason, but I do have to admit that knowing whats going on underneath is useful.
And some of the things he calls out as “oh-no! a framework!” are more library than framework. What stood out to me was Flask, which is a pretty thin abstraction over the http request-response cycle.
I’ve yet to see a web framework I truly enjoy using. Most of them don’t even try to tame the incidental complexity of the web, preferring to heap on even more. I think this is because the type of people that make web frameworks often love the web to the point where they’re blind to the incidental complexity.
These frameworks seem to take special delight in taking over every aspect of your application, because ‘convention.’ Apparently, one of the greatest evils of software development is that there is no standard directory for models unless we institute The Right Way. Meanwhile, massive coupling makes testing difficult, causing years of “Fast tests using this one weird trick” presentations continue to be given.
The best libraries are the ones you can lock away somewhere and forget about.
Enjoyability seems to me to be a bad criterion to judge a tool on. I may enjoy one hammer more than another, but I still need to use specific ones for specific tasks and the ones I enjoy less are no less functional and suitable.
I don’t think the remainder of your post depends on your remark about ‘enjoying’ a web framework, which I feel is extra evidence for that not mattering.
Enjoyability seems to me to be a bad criterion to judge a tool on.
Also “Enjoyability” is based on what timeline you measure it on. If you measure it based on day 1 enjoyability, day 100 enjoyability or day 1000 enjoyability. Stuff like unit testing and fuzzing might not be very enjoyable on day 1 – might be far more enjoyable on day 100 and put you a state of absolute bliss with same testing and fuzzing on day 1000.
Of course web frameworks are not optimal. However, I take the leaky abstraction here and there any time over the mess I have seen with non-framework code. I did Python starting with Python 2.3 which was released in the early 2000s. Back then, I didn’t do Python web development much, yet every now and then I wrote something or looked at options how to do things. This was the time of mod_python and still cgi. Nowadays we have Django, Pyramids and if you feel like having a bit more freedom - Flask. I must say I wouldn’t want to go back.
Potentially, if you have very special requirements, that actively go against the typical patterns, no framework is an option, but other wise it isn’t. at least I wouldn’t like to take over maintenance of such a codebase.
That’s actually quite a nice indicator: “If someone would use that advice, would I like to take over maintenance of that code base?”.
To the people saying “I get what he’s trying to say, but his tone is wrong”, I think you may be misunderstanding him. He straight up said
Why do people like you like frameworks? Are you weak or are you stupid? Or both?
The tone is exactly right for what he’s saying: “if you use frameworks, you’re beneath me.” With a less appropriate tone, we might mistake him for being thoughtful.
“Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can.” Coined by Jamie Zawinski (who called it the “Law of Software Envelopment”) to express his belief that all truly useful programs experience pressure to evolve into toolkits and application platforms (the mailer thing, he says, is just a side effect of that). It is commonly cited, though with widely varying degrees of accuracy.
I am Not a Web Developer, but can someone with a clue help me understand how the author can mix server side and client side Javascript frameworks while making his “FRAMEWORKS BAD!” point?
If he were to restrict himself to Javascript I could see his point, but IMO tarring all web frameworks with the same brush feels less than useful to me.
For instance, frameworks like Django and Rails are superlative tools for building simple CRUD apps which require very little in the way of custom interface. Does anyone really dispute that?
There’s is a new trend now (which i don’t like), it’s to do everything on the client side – except, in most cases, but not always unfortunately, authorization.
So basically people write “micro services” which just served raw data. You can see that as SQL/KV-Store/<whatever database> over HTTP. Because they’re using micro-services “like google in their last blog-post explained”, you can scale the software better in terms of development effort, and request load. (like Facebook said in their blog posts as well) Even though, the software will never be developed by more than 3 devs, and will never have more than 100 concurrent users.
Also because the “micro services” still use MySQL in the background, you will still have a bottleneck on your SQL server (but that’s fine because the “micro-services are stateless” like Amazon recommended in their blog post)
So basically, now, you have this data backend, but you need to create hyper-linkable routes, with rendered HTML data for each routes, forms to insert/update new data, and so on… (What Django and Rails would do: CRUD) So people use full client side Javascript framework to do so.
The real advantages are that:
this is cool and hipster. (Investors love it. You just have to put some machine learning on top of it)
You have “separation of concerns” (whatever that means, because you end up with spagghetti because of the third point)
You can hire cheap “frontend engineers” (5 years ago they were called designers) or right out of school juniors (usually they learned basic javascript at school)
You can write brittle tests in Selenium (or don’t write any test at all, and have a “QA person” click through the app every time you deploy)
While there are definitely some former designers working in JS on the client side, it’s far from the majority. And if you want a client side application done well, you can’t just hire cheap “frontend engineers” or you get a mess like you used to have. You should still unit and integration test aside from e2e test on the client regardless of what the server side is.
We can’t really argue on this, because there’s no data back up any of our points. I don’t claim that all “frontend engineers” were designers. I know that my original comment was implying it, but I was making the generalization as part of the joke/satire tone of my original comment.
The bottom line is: you’re right, there are many frontend engineers who have real engineering background (many people working on react.js, or on facebook’s frontend, the designers of Elm, …) However, I disagree when you claim they’re are the vast majority.
I don’t have any number to back up my claim, but that’s true: if you just read comments and pull request on Github’s react.js project, you might think “most frontend engineers are engineers.” However, I haven’t seen that in my experience working with many companies: JavaScript is considered a toy language, very junior (with no experience) engineers are hired. Or former designers who could figure jQuery now write full single page application (in react or angular)
The result in general is a buggy result, with no tests, all the possible bad practices, okay working. And when “the guy” (or “the gal” doesn’t matter) leaves the next “frontend engineer” just rewrites it. (and the next, and the next, …)
I’m not sure on your experience, but I’ve worked at a lot of companies and I’ve only heard a few elitist types of individuals who called JS a toy language or assumed just anyone can do it. I’ve heard that on the server side when it comes to PHP from the same types, though.
I think you’re being unnecessarily harsh on client side work in general when server side work is often just as buggy, untested, and just enough to “work” now and again to keep the team going with the worst possible practices. It’s not a client vs server thing, it’s just a fact of working in the “engineering” umbrella.
That said, I’ve worked with a ton of people who never went to school for CS or anything even related (myself included) who don’t even consider themselves engineers. My title says it, but that only changed within the last 5 years or so. It used to say “developer.” It’s a marketing thing for companies to say devs are “engineers” because people attach some significance to that term, but not to “developers.”
You couldn’t be more right on this ine. I am working as a freelance developer and the last 3 out of 5 projects were exactly that: Throwing buzzwords around, glueing stuff together. Using micro services but still have so many dependencies between each module that it’s basically a harder to seploy monolith.
I’m currently building one of those websites that does everything in the frontend. There are a bunch of real advantages. My primary reason was I want to write a very efficient server app for when I get more usage but for now it would be best to continue using rails because thats what I know best so I want the backend to be fairly easy to replace later and not having any app logic in it makes that a whole lot easier. The backend is mainly just an api over a database which validates things the client sends.
Another advantage is you get a rock solid, complete API for other people to use with no extra effort. Most online services have websites that do things that simply can not be done via the API. When making an app that just exchanges JSON with the server you end up with an API that can do everything the website can. Someone else could make an alternative website using my backend and there would be no issues.
Also after the first page load it will actually require less data sent over the network because the whole website logic is cached and only a tiny bit of json is sent on page loads.
Of course there are many advantages. I don’t deny them: no reload is cool, having a universal API is nice, heavy caching of the static assets is awesome, …
But there are many disadvantages:
Was SEO finally fixed? When I was still on the topic people used to serve an alternative page to google to get indexed. I heard that now google was running a full javascript engine in their crawlers. Is that fixed now? I haven’t checked further. You might say “We don’t care about SEO”, but as a user of your website, I want to be able to use google/bing/duckduckgo instead of your badly performing internal search engine when I’m looking for content.
There are still disparities between javascript dialects of each browsers last time I heard. If you do a server-side rendered website, you just have to care about HTML/CSS, now it’s one more language to support.
You will most definitely break on legacy browsers (IE6 which is still used in China), or text based browsers. (Lynx, w3m, …)
Your single page application (SPA) might not have all the correct aria elements for disabled people and screen readers: If you just do links and buttons with label, most screen readers will get it right.
You have to handle things that the browsers does for you. For example you click on a link, and the network goes down, the browser display a page “connectivity issues”. With an SPA, you have to handle failures and display the message yourself when your XHR request fails.
That’s just the technical side. What I’ve seen is the mess it brings on the human level. Of course in you’re case if you’re alone, or with compatible developer, it will be smooth. But I’ve seen teams split by management or the employees themselves.
Either management says “we need to share the work load, let’s have a ‘frontend team’ and a ‘backend team’.” Or, in some other case, the employees have the mindset “I’m a frontend dev, I don’t do Python”, “I do backend, not javascript”, … In both cases, you have huge friction “when do you send when I request that?”, “you told me you added this feature but it doesn’t work on staging!”, …
Thanks for the comments. Those are some pretty good points. I’m currently working on this myself and just working things out.
Was SEO finally fixed? When I was still on the topic people used to serve an alternative page to google to get indexed. I heard that now google was running a full javascript engine in their crawlers. Is that fixed now? I haven’t checked further. You might say “We don’t care about SEO”, but as a user of your website, I want to be able to use google/bing/duckduckgo instead of your badly performing internal search engine when I’m looking for content.
I’m not really sure but my website doesn’t really have much searchable stuff anyway. It’s mainly based around maps where 90% of the data you look at is uploaded by you.
You will most definitely break on legacy browsers (IE6 which is still used in China), or text based browsers. (Lynx, w3m, …)
I’m not really concerned about this as my mapping library also doesn’t work on these also my website is probably automatically banned from china for being not hosted there.
Your single page application (SPA) might not have all the correct aria elements for disabled people and screen readers: If you just do links and buttons with label, most screen readers will get it right.
The framework I am using makes it very easy to control the HTML that gets generated so I have had no issues making accessible pages
Overall it’s worse in some ways and better in others. I’m not sure if its the best way to do things but it has been a great learning experience.
If you do something with maps, heavy interactive (like google maps), and very little text. I think you don’t have any other choice: doing single page application is fine. (and maybe best)
In most cases, I’ve seen people write CRUD single page application. (Like an ERP) I consider that non-sense.
While I am sympathetic to this approach in general, I think that there’s a reason that Frameworks are developed and adopted, mainly because (as it seems to me) 75% of all the problems one encounters are the same. How many services transform SQL queries into some sort of HTML? What we call “the web” has lost it’s real connection to the WWW long ago. And ultimately it’s potential is to blame.
Connected to that issue, the WWW is a great example of legacy standards stacking themselves one over another. I was just working on a project with pure js, and I had to look up, since I usually don’t do webdev, how cookies are managed… and it isn’t pretty. But one has to say, the author is right, things are getting better. Especially with HTML and CSS. JavaScript will probably take a bit longer, but until all of this finishes and the standards proliferate, who knows what new ideas and desires the web designers and managers will have? Probably won’t be brutalism.
I usually lurk on here but this is one of the most infuriating posts I’ve ever seen.
Using a framework does not make you a bad developer, having the hubris to believe you are better than everyone else because you don’t does. The worst part of doing this is eventually creating your own random framework that does 90% of what for instance rails does in some arbitrary way that’s probably worse thought out and you have to support forever.
I think practically all “Why You Should…” articles would be improved if they became “When You Should…” articles with corresponding change of perspective.
An even better formulation would be “Here is the source code for an app where I didn’t use a framework. It has users, and here are my observations on building and deploying it”.
In other words, “skin in the game” (see Taleb). I basically ignore everyone’s “advice” and instead look at what they do, not what they say. I didn’t see this author relate his or her own experience.
The problem with “when you should” is that the author is not in the same situation as his audience. There are so many different programming situations you can be in, with different constraints, and path dependence. Just tell people what you did and they can decide whether it applies to them. I think I basically follow that with http://www.oilshell.org/ – I am telling people what I did and not attempting to give advice.
(BTW I am sympathetic to no framework – I use my own little XHR wrapper and raw JS, and my own minimal wrapper over WSGI and Python. But yes it takes forever to get things done!)
Thanks for the Taleb reference. I didn’t know it existed, and so far it is a good read.
His earlier books are also good. It is a lot of explaining the same ideas in many different ways, but I find that the ideas need awhile to sink in, so that’s useful.
He talks about people thinking/saying one thing, but then acting like they believe its opposite. I find that to be painfully true, and it also applies to his books. You could agree with him in theory, but unless you change your behavior then you might not have gotten the point :-)
Less abstractly, the worst manager I ever had violated the “skin in the game” rule. He tried to dictate the technology used in a small project I was doing, based on conversations with his peers. That technology was unstable and inappropriate for the task.
He didn’t have to write the code, so he didn’t care. I was the one who had to write the code, so I’m the one with skin in the game, so I should make the technology choices. I did what he asked and left the team, but what he asked is not what the person taking over wanted I’m sure.
In software, I think you can explain a lot of things by “who has to maintain the code” (who has skin in the game). I think it explains why the best companies maintain long term software engineering staff, instead of farming it out. If you try to contract out your work, those people may do a shitty job because they might only be there for a short period. (Maybe think of the healthcare.gov debacle – none of the engineers really had skin in the game.)
It also explains why open source code can often be higher quality, and why it lasts 30+ years in many cases. If the original designer plans on maintaining his or her code for many years, then that code will probably be maintainable by others too.
It also explains why “software architect” is a bad idea and never worked. (That is, a person who designs software but doesn’t implement it.)
I’m sure these principles existed under different names before, and are somewhat common sense. But they do seem to be violated over and over, so I like to have a phrase to call people on their BS. :-)
Yeah, the phrase works as a good lens and reminder. Interestingly, as most parents will attest to - the “do as I say not as I do” is generally unsuccessful with kids. They are more likely to emulate than listen.
I definitely agree with this change. It’d get more people thinking architecturally, something that’s sorely needed.
IMHO this article could have done a much better job of saying “don’t blindly trust the framework but also think about how things work underneath”.
I do get the point that the author is trying to convey. But unfortunately the language that’s used and the tone in which it’s conveyed makes the advice come off wrong-ish.
It took me half way through the article to realize the author is probably serious. The tone of the language lends itself to parody very well.
I agree. At first, when I read the title, I thought “ohh.. We’re just going to disagree on this one…”. I had to maintain countless Python application just doing SQL/CRUD and the previous engineer either glued Flask and SQLAlchemy together in a bad way, or worse invented their own framework based on WSGI. And every-time, I just migrated it to Django with half to a tenth of the original lines of codes.
Then, I read the article, and all it says is “please understand how frameworks work under the hood”. Which I totally agree with, and that’s what I always teach juniors when I train them with Django or Flask.
In a nutshell, the title is totally clickbait.
I have been at a few companies who have decided to do this while I was there. I have also joined a number of companies like this after the direction has already been taken. People need to realize what decisions they are making, and think about the future more often. This is almost always not the right call.
…Oh, damn! It looks like this is the “I Have NIHS and Want to Build My Own Framework With Less Commuity Support Manifesto”.
I highly recommend avoiding this story. It sounds so easy, but it is hard. Small things become big things. Big things become bigger things. So many things become SO MANY THINGS. Nobody outside of your company knows wtf your thing is, because there isn’t a community fostering it.
You probably won’t believe me now, but when someone can recreate your 2-year-old startup from scratch with higher quality code in 3 months because they were smart enough to choose the right tools while you were off in play land inventing your own, you’ll realize this. It’s a huge time sink that is easy to avoid when you’re only seeing the day-to-day and not focused on the month-to-month.
Its not that nobody knows how this stuff works when they use a web framework, its just that nobody wants to invest the time to make the same mistakes as other when it comes to edge cases and the like.
I dont know how this article is aimed at, but for someone who knows how this stuff works it’d be a PITA to rewrite everything from scratch for no good reason, but I do have to admit that knowing whats going on underneath is useful.
And some of the things he calls out as “oh-no! a framework!” are more library than framework. What stood out to me was Flask, which is a pretty thin abstraction over the http request-response cycle.
okay, I just opened a socket. How do I go from here? /s
I’d like to see a C++ developer reimplementing Qt to distribute software because he shouldn’t trust Qt.
Learn the basics not someone else’s abstraction….
Except that the basics ARE just someone else’s abstraction.
You either use an existing framework, or you end up re-inventing one… poorly.
I’ve yet to see a web framework I truly enjoy using. Most of them don’t even try to tame the incidental complexity of the web, preferring to heap on even more. I think this is because the type of people that make web frameworks often love the web to the point where they’re blind to the incidental complexity.
These frameworks seem to take special delight in taking over every aspect of your application, because ‘convention.’ Apparently, one of the greatest evils of software development is that there is no standard directory for
modelsunless we institute The Right Way. Meanwhile, massive coupling makes testing difficult, causing years of “Fast tests using this one weird trick” presentations continue to be given.The best libraries are the ones you can lock away somewhere and forget about.
Enjoyability seems to me to be a bad criterion to judge a tool on. I may enjoy one hammer more than another, but I still need to use specific ones for specific tasks and the ones I enjoy less are no less functional and suitable.
I don’t think the remainder of your post depends on your remark about ‘enjoying’ a web framework, which I feel is extra evidence for that not mattering.
Also “Enjoyability” is based on what timeline you measure it on. If you measure it based on day 1 enjoyability, day 100 enjoyability or day 1000 enjoyability. Stuff like unit testing and fuzzing might not be very enjoyable on day 1 – might be far more enjoyable on day 100 and put you a state of absolute bliss with same testing and fuzzing on day 1000.
Of course web frameworks are not optimal. However, I take the leaky abstraction here and there any time over the mess I have seen with non-framework code. I did Python starting with Python 2.3 which was released in the early 2000s. Back then, I didn’t do Python web development much, yet every now and then I wrote something or looked at options how to do things. This was the time of
mod_pythonand still cgi. Nowadays we have Django, Pyramids and if you feel like having a bit more freedom - Flask. I must say I wouldn’t want to go back.Potentially, if you have very special requirements, that actively go against the typical patterns, no framework is an option, but other wise it isn’t. at least I wouldn’t like to take over maintenance of such a codebase.
That’s actually quite a nice indicator: “If someone would use that advice, would I like to take over maintenance of that code base?”.
Please, don’t start this again… It’s like reading “why you should re-implement security related stuff yourself”.
Lumping together Bootstrap and Angular as Web frameworks was definitely an interesting choice…
To the people saying “I get what he’s trying to say, but his tone is wrong”, I think you may be misunderstanding him. He straight up said
The tone is exactly right for what he’s saying: “if you use frameworks, you’re beneath me.” With a less appropriate tone, we might mistake him for being thoughtful.
Sad, but true, is Joe’s Law : `Frameworks grow in complexity until nobody can use them.’
Similar to Zawinski’s Law:
“Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can.” Coined by Jamie Zawinski (who called it the “Law of Software Envelopment”) to express his belief that all truly useful programs experience pressure to evolve into toolkits and application platforms (the mailer thing, he says, is just a side effect of that). It is commonly cited, though with widely varying degrees of accuracy.
I am Not a Web Developer, but can someone with a clue help me understand how the author can mix server side and client side Javascript frameworks while making his “FRAMEWORKS BAD!” point?
If he were to restrict himself to Javascript I could see his point, but IMO tarring all web frameworks with the same brush feels less than useful to me.
For instance, frameworks like Django and Rails are superlative tools for building simple CRUD apps which require very little in the way of custom interface. Does anyone really dispute that?
There’s is a new trend now (which i don’t like), it’s to do everything on the client side – except, in most cases, but not always unfortunately, authorization.
So basically people write “micro services” which just served raw data. You can see that as SQL/KV-Store/<whatever database> over HTTP. Because they’re using micro-services “like google in their last blog-post explained”, you can scale the software better in terms of development effort, and request load. (like Facebook said in their blog posts as well) Even though, the software will never be developed by more than 3 devs, and will never have more than 100 concurrent users.
Also because the “micro services” still use MySQL in the background, you will still have a bottleneck on your SQL server (but that’s fine because the “micro-services are stateless” like Amazon recommended in their blog post)
The climax of this trend is GraphQL.
So basically, now, you have this data backend, but you need to create hyper-linkable routes, with rendered HTML data for each routes, forms to insert/update new data, and so on… (What Django and Rails would do: CRUD) So people use full client side Javascript framework to do so.
The real advantages are that:
PROFIT!
While there are definitely some former designers working in JS on the client side, it’s far from the majority. And if you want a client side application done well, you can’t just hire cheap “frontend engineers” or you get a mess like you used to have. You should still unit and integration test aside from e2e test on the client regardless of what the server side is.
We can’t really argue on this, because there’s no data back up any of our points. I don’t claim that all “frontend engineers” were designers. I know that my original comment was implying it, but I was making the generalization as part of the joke/satire tone of my original comment.
The bottom line is: you’re right, there are many frontend engineers who have real engineering background (many people working on react.js, or on facebook’s frontend, the designers of Elm, …) However, I disagree when you claim they’re are the vast majority.
I don’t have any number to back up my claim, but that’s true: if you just read comments and pull request on Github’s react.js project, you might think “most frontend engineers are engineers.” However, I haven’t seen that in my experience working with many companies: JavaScript is considered a toy language, very junior (with no experience) engineers are hired. Or former designers who could figure jQuery now write full single page application (in react or angular)
The result in general is a buggy result, with no tests, all the possible bad practices, okay working. And when “the guy” (or “the gal” doesn’t matter) leaves the next “frontend engineer” just rewrites it. (and the next, and the next, …)
I’m not sure on your experience, but I’ve worked at a lot of companies and I’ve only heard a few elitist types of individuals who called JS a toy language or assumed just anyone can do it. I’ve heard that on the server side when it comes to PHP from the same types, though.
I think you’re being unnecessarily harsh on client side work in general when server side work is often just as buggy, untested, and just enough to “work” now and again to keep the team going with the worst possible practices. It’s not a client vs server thing, it’s just a fact of working in the “engineering” umbrella.
That said, I’ve worked with a ton of people who never went to school for CS or anything even related (myself included) who don’t even consider themselves engineers. My title says it, but that only changed within the last 5 years or so. It used to say “developer.” It’s a marketing thing for companies to say devs are “engineers” because people attach some significance to that term, but not to “developers.”
You couldn’t be more right on this ine. I am working as a freelance developer and the last 3 out of 5 projects were exactly that: Throwing buzzwords around, glueing stuff together. Using micro services but still have so many dependencies between each module that it’s basically a harder to seploy monolith.
I’m currently building one of those websites that does everything in the frontend. There are a bunch of real advantages. My primary reason was I want to write a very efficient server app for when I get more usage but for now it would be best to continue using rails because thats what I know best so I want the backend to be fairly easy to replace later and not having any app logic in it makes that a whole lot easier. The backend is mainly just an api over a database which validates things the client sends.
Another advantage is you get a rock solid, complete API for other people to use with no extra effort. Most online services have websites that do things that simply can not be done via the API. When making an app that just exchanges JSON with the server you end up with an API that can do everything the website can. Someone else could make an alternative website using my backend and there would be no issues.
Also after the first page load it will actually require less data sent over the network because the whole website logic is cached and only a tiny bit of json is sent on page loads.
Of course there are many advantages. I don’t deny them: no reload is cool, having a universal API is nice, heavy caching of the static assets is awesome, …
But there are many disadvantages:
That’s just the technical side. What I’ve seen is the mess it brings on the human level. Of course in you’re case if you’re alone, or with compatible developer, it will be smooth. But I’ve seen teams split by management or the employees themselves.
Either management says “we need to share the work load, let’s have a ‘frontend team’ and a ‘backend team’.” Or, in some other case, the employees have the mindset “I’m a frontend dev, I don’t do Python”, “I do backend, not javascript”, … In both cases, you have huge friction “when do you send when I request that?”, “you told me you added this feature but it doesn’t work on staging!”, …
Thanks for the comments. Those are some pretty good points. I’m currently working on this myself and just working things out.
I’m not really sure but my website doesn’t really have much searchable stuff anyway. It’s mainly based around maps where 90% of the data you look at is uploaded by you.
I’m not really concerned about this as my mapping library also doesn’t work on these also my website is probably automatically banned from china for being not hosted there.
The framework I am using makes it very easy to control the HTML that gets generated so I have had no issues making accessible pages
Overall it’s worse in some ways and better in others. I’m not sure if its the best way to do things but it has been a great learning experience.
If you do something with maps, heavy interactive (like google maps), and very little text. I think you don’t have any other choice: doing single page application is fine. (and maybe best)
In most cases, I’ve seen people write CRUD single page application. (Like an ERP) I consider that non-sense.
Agree, frameworks are terrible. Dependencies should be minimal and orthogonal. I can connect the legos myself, no need for a lego frame.
While I am sympathetic to this approach in general, I think that there’s a reason that Frameworks are developed and adopted, mainly because (as it seems to me) 75% of all the problems one encounters are the same. How many services transform SQL queries into some sort of HTML? What we call “the web” has lost it’s real connection to the WWW long ago. And ultimately it’s potential is to blame.
Connected to that issue, the WWW is a great example of legacy standards stacking themselves one over another. I was just working on a project with pure js, and I had to look up, since I usually don’t do webdev, how cookies are managed… and it isn’t pretty. But one has to say, the author is right, things are getting better. Especially with HTML and CSS. JavaScript will probably take a bit longer, but until all of this finishes and the standards proliferate, who knows what new ideas and desires the web designers and managers will have? Probably won’t be brutalism.
The tone of this article made it very hard to take the author seriously.
That said, make an educated choice whether to use a framework or not. I don’t think it’s so black and white.
I usually lurk on here but this is one of the most infuriating posts I’ve ever seen.
Using a framework does not make you a bad developer, having the hubris to believe you are better than everyone else because you don’t does. The worst part of doing this is eventually creating your own random framework that does 90% of what for instance rails does in some arbitrary way that’s probably worse thought out and you have to support forever.
[Comment removed by author]