8 ms·

I’m tempted to step back and evaluate this on another level. Our industry is very big, and any industry that gets that big will be able to house a lot of people

I’m tempted to step back and evaluate this on another level. Our industry is very big, and any industry that gets that big will be able to house a lot of people just for the sake of it. If you think we have a large amount of fresh frontend people, understand they are hired almost with a one to one correspondence with fresh product/business people. Modern product development is essentially a polishing job on every component that Twitter Bootstrap or Jquery UI ever invented. Over and over, we dress up a modal, with a slider, with a ‘user flow’, with some tooltips, and so on, and allow the process to masquerade around as real design/engineering. There’s so much money in this industry that we can hire entire teams to basically take a Bootstrap component, and theme it. This gets passed on as product development, and from the developer side, it gets passed on as engineering. If this is the level of masquerading occurring, why would a frontend developer ever go ‘what’s the right solution here?’. Something similar is happening on the backend and infrastructure. It too will take on a mask behind devops and data science and start pumping out what are probably straight up SQL queries and cron jobs. This will get passed off as design and engineering as well. We’re too big.

ngold 6y ago
And yet, unlike newspapers with an in house advertising staff. All web adverts are 3rd party. That are easily blocked. Google laughs to the bank everyday it killed old advertising.
PaulDavisThe1st 6y ago
What do you consider "our industry" to be ? Software development? Web development? What used to be called "Application Development" back in the 1980s and early 1990s? I'm asking because there's a lot of software developers/engineers whose jobs don't feature any of the keywords in your comment ("Frontend", "Backend", "SQL queries", "modal" etc. etc.)
- aryehof 6y ago
  If all one has been exposed is a development world of web-based consumer-facing front-ends (CFUI), it is hard to imagine that the majority of software lies elsewhere. Hard to imagine that anything else is important. It leads to a viewpoint that modern programming is mainly about UI interacting with a database.
  - TeMPOraL 6y ago
    I'd say you have to group business-facing front ends with consumer-facing front ends, as well as big chunk of mobile development, because all of these are done by the same people from the same programming culture, with the same technologies, patterns and ways of thinking. And with that, I'd argue this is majority of software.
    - tsimionescu 6y ago
      By what measure? Majority of individual 'products'? Majority of programmers? Majority of investment? Majority of revenue? I think that at best what you're describing is a thin simple majority by some of those metrics. But there are so many developers working on factory automation, networking, gaming, small embedded systems (anything with a chip in it, from washing machines to cars), not to mention the huge frameworks that power am off the simple apps you are taking about - Linux, Windows, Chrome, Firefox, Android, iOS, the major SQL DBs, the major NoSQL DBs, the language tools for all of these, the web servers, the distribution frameworks at Google/Facebook/Microsoft/Amazon and so on. While the number of core technologies is obviously easily dwarfed by the number of applications, the number of people working on each of these core technologies is so large that I can't believe your assumption. Also, some of these industries, particularly gaming, and maybe networking as well, are so huge in terms of revenue, that I don't think CRUD apps could win on that side either.
      - TeMPOraL 6y ago
        I'd say majority of programmer-hours, because anything else is a metric that's too unreliable / easy to fudge. "Individual products" is an arbitrary marketing distinction (e.g. a company I worked for could create and sell new products by tweaking few lines in a config file; every customer would get their own mix and match of software pieces). And neither investments nor revenue are directly correlated with the amount of software you have. Note also that out of the things you mentioned, "factory automation, networking, gaming, small embedded systems", perhaps only small embedded systems projects aren't partly done in web technologies. Gaming definitely is (in AAA games, all the UI that's not the part of core gameplay - e.g. launchers, lobby, marketplace - is likely to be done in Electron or some embeddable webview library). Factory automation, if two companies I worked with over the last decade are any indication, is slowly moving towards webapps for everything. So I imagine networking on the admin side. It's basically too cheap to make a shit, bloated but somewhat pretty UI with JavaScript. Everyone's doing it, everyone keeps hiring for it.
save_ferris 6y ago
> There’s so much money in this industry that we can hire entire teams to basically take a Bootstrap component, and theme it. This feels a tad reductionist based on my experience. Sure, most apps are designed around an agreed-upon set of affordances and design principles that the community determines, but modeling application behavior for real-world scenarios involves way more than theming a bootstrap component. I think it’s a mistake to reduce a developer down to the code that they write, because the ultimate value of a developer is in the code that they choose not to write just as much as the code they do write.
Polylactic_acid 6y ago
The alternative is just having premade components lazily glued together. It seems that the markets have decided that highly polished custom tools are worth the cost.
- ako 6y ago
  Low code and no-code markets are growing rapidly, so don't be sure the markets have decided.
  - Nextgrid 6y ago
    "Growth" != profit. I can sell $10 bills for $1 and grow rapidly too, doesn't mean I will ever become profitable. Are these low/no-code providers actually making profits, or is it a temporary fad and eventually 1) the market will re-adjust and these no-code tools will become more expensive to sustain themselves, bringing up the cost of a no-code app and/or 2) users of these tools will realise their limitations and eventually word will get out that you end up spending twice as much with no-code than doing "code" to begin with?
MattyRad 6y ago
I think you're bordering on a contentious idea that I will take a step further. I would argue that frontend, nearly in its entirety, is effectively one giant bike-shed operation. And like you're alluding to, it's an operation that exists mostly because there is money to burn. At best, frontend exists to save backend engineers the trouble of dealing with the tedium of HTML/CSS. As an example, the article brought up Craigslist; renowned for its brutalism. Craigslist would only be hindered by any frontend changes: arbitrary and confusing interface changes, (necessarily) slower load times, and increased complexity. That said, I agree with the article that HTML form UX often requires more advance strategies like React and Vue. The decision requires discretion, of course.
- dbmikus 6y ago
  I'm actually more of the opinion that a lot of backend is bikeshedding! Branding and UI/UX design are very important for emotionally influencing a customer's opinion or improving their user experience with your product. On the backend, how often are the any different than some cross set of options from: * synchronous CRUD * async data flow * bidirectional realtime messaging (message in the "data packet" sense) * search Most products are not serving traffic that is large enough or solving a computational problem that distinct enough to not be covered by some off the shelf combination of the above. We just haven't figured out how to make these different solutions composable on the backend. Over the next 10 years I think we're going to see more and more codeless SaaS services, like Webflow for the backend.
  - unclebucknasty 6y ago
    >Over the next 10 years I think we're going to see more and more codeless SaaS services Maybe it will finally happen, but some variation of this has been the holy grail for a lot of years now. I read an article a while back that talked about how many times developers have implemented the same thing in different ways at different companies; for instance payment processing. And it's true. But, you have companies like Stripe and Braintree. Now, there's even a SaaS subscription management SaaS businesses that sit above these (I don't recall any names). But these just become other things to which we have to integrate. Now the task has moved, but we still have to build the connections and implement all of the business rules that go around that. I guess my point is that with every business having different logic, processes, models, etc it becomes very difficult to have some generic tool that allows a codeless solution to all of these problems. It's not the individual components like those you listed that cause the complexity. It's the way they are wired together and the underlying rules. So, while it seems inefficient to keep building these things, I think it is reductionist to say "well, it's only another CRUD app" or whatever. Sure, tools can make things easier, but they make things easier for everyone. So now the bar is raised in terms of what you must do over and above that baseline in order to win. Maybe a good analogy is that back in the day everything was written in assembly. High level languages came along and made it easier to do more faster. But then the complexity of software and the demands on it also increased, so in a similar fashion it just moved the problem.
bryanrasmussen 6y ago
Since 2013 my work has generally consisted of applications that run in the browser, right now I'm working on the first normal website I've worked on in 7 years. And I agree this is a bunch of little polishing jobs. I do say to myself what's the right solution here, but I know for business reasons I am not allowed to do the right solution.
_630w 6y ago
<rant> At this point, I am convinced the problem is not web frameworks but browsers. Someone needs to take all the legacy bloat away and put it in the side while starting from the scratch. Web doesn't need three different languages. It doesn't need freedom that costs accessibility. It doesn't need to be so primitive. It smells. Awful defaults. import "reset.css" import "reset.js" </rant>
- unclebucknasty 6y ago
  I'll take it a step further and say we shouldn't be using the Web paradigm at all. We've tried a million different ways now to essentially generate HTML. So many frameworks. So many libraries. Front end. Back end. Etc. But, we're still working within the paradigm of the stateless Web, designed to display documents and images. Trying to hammer an application in there (especially a SPA) really doesn't make sense. So, why do we just keep forcing it? If leveraging the ubiquity of the Web is the objective, then there's nothing to say we couldn't have a VM running in a browser that itself uses web protocols/languages, but abstracts them away. That would leave us writing code a la Swing, an event-driven, component-based model that makes so much more sense for a GUI style application. No CSS, HTML, fighting back-buttons, state management, routing, etc. That's all handled in the VM.
  - pbourke 6y ago
    > So, why do we just keep forcing it? Because hyperlinked documents are the whole ball game. Web technologies are a pain in the ass for developers but a boon for the advancement of human knowledge and connectedness. The great islands and continents of web space float in the same aether. They interconnect, despite being built at different times, in different styles, on different technologies. It all just, for the most part, works. It’s fucking beautiful. The system is greater than the sum of its parts.
    - unclebucknasty 6y ago
      My comment was WRT to a better model for developing SPAs and complex Webapps, not sunsetting the Web in general.
joeberon 6y ago
Isn't this the same in almost any industry? For example, in engineering this kind of "reinventing the wheel ad infinitum" you are describing is incredibly common. How many times to you think engineers have separately designed and tested clips to hold capacitors in place in the ECU of a motor? Many thousands of times, while being paid competitive salaries. Maybe you should argue there should be some "book of capacitor clip designs" but actually this doesn't work in practise because every capacitor clip design needs to fulfil very slightly different requirements. Often it is just easier and faster to redesign from scratch. Taking existing components and redesigning them in some small way to fit your specific requirements is common in almost every industry I can think of.
dilandau 6y ago
Nice take. Yes design/frontend has rarely been about actual design. Backend web has rarely been about engineering either, I'd say. Just look at all the elastic search engines left open to the public internet as proof of unconscionable levels of ignorance.

ngold 6y ago

And yet, unlike newspapers with an in house advertising staff. All web adverts are 3rd party. That are easily blocked. Google laughs to the bank everyday it killed old advertising.

PaulDavisThe1st 6y ago

What do you consider "our industry" to be ? Software development? Web development? What used to be called "Application Development" back in the 1980s and early 1990s? I'm asking because there's a lot of software developers/engineers whose jobs don't feature any of the keywords in your comment ("Frontend", "Backend", "SQL queries", "modal" etc. etc.)

aryehof 6y ago
If all one has been exposed is a development world of web-based consumer-facing front-ends (CFUI), it is hard to imagine that the majority of software lies elsewhere. Hard to imagine that anything else is important. It leads to a viewpoint that modern programming is mainly about UI interacting with a database.
- TeMPOraL 6y ago
  I'd say you have to group business-facing front ends with consumer-facing front ends, as well as big chunk of mobile development, because all of these are done by the same people from the same programming culture, with the same technologies, patterns and ways of thinking. And with that, I'd argue this is majority of software.
  - tsimionescu 6y ago
    By what measure? Majority of individual 'products'? Majority of programmers? Majority of investment? Majority of revenue? I think that at best what you're describing is a thin simple majority by some of those metrics. But there are so many developers working on factory automation, networking, gaming, small embedded systems (anything with a chip in it, from washing machines to cars), not to mention the huge frameworks that power am off the simple apps you are taking about - Linux, Windows, Chrome, Firefox, Android, iOS, the major SQL DBs, the major NoSQL DBs, the language tools for all of these, the web servers, the distribution frameworks at Google/Facebook/Microsoft/Amazon and so on. While the number of core technologies is obviously easily dwarfed by the number of applications, the number of people working on each of these core technologies is so large that I can't believe your assumption. Also, some of these industries, particularly gaming, and maybe networking as well, are so huge in terms of revenue, that I don't think CRUD apps could win on that side either.
    - TeMPOraL 6y ago
      I'd say majority of programmer-hours, because anything else is a metric that's too unreliable / easy to fudge. "Individual products" is an arbitrary marketing distinction (e.g. a company I worked for could create and sell new products by tweaking few lines in a config file; every customer would get their own mix and match of software pieces). And neither investments nor revenue are directly correlated with the amount of software you have. Note also that out of the things you mentioned, "factory automation, networking, gaming, small embedded systems", perhaps only small embedded systems projects aren't partly done in web technologies. Gaming definitely is (in AAA games, all the UI that's not the part of core gameplay - e.g. launchers, lobby, marketplace - is likely to be done in Electron or some embeddable webview library). Factory automation, if two companies I worked with over the last decade are any indication, is slowly moving towards webapps for everything. So I imagine networking on the admin side. It's basically too cheap to make a shit, bloated but somewhat pretty UI with JavaScript. Everyone's doing it, everyone keeps hiring for it.

save_ferris 6y ago

> There’s so much money in this industry that we can hire entire teams to basically take a Bootstrap component, and theme it. This feels a tad reductionist based on my experience. Sure, most apps are designed around an agreed-upon set of affordances and design principles that the community determines, but modeling application behavior for real-world scenarios involves way more than theming a bootstrap component. I think it’s a mistake to reduce a developer down to the code that they write, because the ultimate value of a developer is in the code that they choose not to write just as much as the code they do write.

Polylactic_acid 6y ago

The alternative is just having premade components lazily glued together. It seems that the markets have decided that highly polished custom tools are worth the cost.

ako 6y ago
Low code and no-code markets are growing rapidly, so don't be sure the markets have decided.
- Nextgrid 6y ago
  "Growth" != profit. I can sell $10 bills for $1 and grow rapidly too, doesn't mean I will ever become profitable. Are these low/no-code providers actually making profits, or is it a temporary fad and eventually 1) the market will re-adjust and these no-code tools will become more expensive to sustain themselves, bringing up the cost of a no-code app and/or 2) users of these tools will realise their limitations and eventually word will get out that you end up spending twice as much with no-code than doing "code" to begin with?

MattyRad 6y ago

I think you're bordering on a contentious idea that I will take a step further. I would argue that frontend, nearly in its entirety, is effectively one giant bike-shed operation. And like you're alluding to, it's an operation that exists mostly because there is money to burn. At best, frontend exists to save backend engineers the trouble of dealing with the tedium of HTML/CSS. As an example, the article brought up Craigslist; renowned for its brutalism. Craigslist would only be hindered by any frontend changes: arbitrary and confusing interface changes, (necessarily) slower load times, and increased complexity. That said, I agree with the article that HTML form UX often requires more advance strategies like React and Vue. The decision requires discretion, of course.

dbmikus 6y ago
I'm actually more of the opinion that a lot of backend is bikeshedding! Branding and UI/UX design are very important for emotionally influencing a customer's opinion or improving their user experience with your product. On the backend, how often are the any different than some cross set of options from: * synchronous CRUD * async data flow * bidirectional realtime messaging (message in the "data packet" sense) * search Most products are not serving traffic that is large enough or solving a computational problem that distinct enough to not be covered by some off the shelf combination of the above. We just haven't figured out how to make these different solutions composable on the backend. Over the next 10 years I think we're going to see more and more codeless SaaS services, like Webflow for the backend.
- unclebucknasty 6y ago
  >Over the next 10 years I think we're going to see more and more codeless SaaS services Maybe it will finally happen, but some variation of this has been the holy grail for a lot of years now. I read an article a while back that talked about how many times developers have implemented the same thing in different ways at different companies; for instance payment processing. And it's true. But, you have companies like Stripe and Braintree. Now, there's even a SaaS subscription management SaaS businesses that sit above these (I don't recall any names). But these just become other things to which we have to integrate. Now the task has moved, but we still have to build the connections and implement all of the business rules that go around that. I guess my point is that with every business having different logic, processes, models, etc it becomes very difficult to have some generic tool that allows a codeless solution to all of these problems. It's not the individual components like those you listed that cause the complexity. It's the way they are wired together and the underlying rules. So, while it seems inefficient to keep building these things, I think it is reductionist to say "well, it's only another CRUD app" or whatever. Sure, tools can make things easier, but they make things easier for everyone. So now the bar is raised in terms of what you must do over and above that baseline in order to win. Maybe a good analogy is that back in the day everything was written in assembly. High level languages came along and made it easier to do more faster. But then the complexity of software and the demands on it also increased, so in a similar fashion it just moved the problem.

bryanrasmussen 6y ago

Since 2013 my work has generally consisted of applications that run in the browser, right now I'm working on the first normal website I've worked on in 7 years. And I agree this is a bunch of little polishing jobs. I do say to myself what's the right solution here, but I know for business reasons I am not allowed to do the right solution.

_630w 6y ago

<rant> At this point, I am convinced the problem is not web frameworks but browsers. Someone needs to take all the legacy bloat away and put it in the side while starting from the scratch. Web doesn't need three different languages. It doesn't need freedom that costs accessibility. It doesn't need to be so primitive. It smells. Awful defaults. import "reset.css" import "reset.js" </rant>

unclebucknasty 6y ago
I'll take it a step further and say we shouldn't be using the Web paradigm at all. We've tried a million different ways now to essentially generate HTML. So many frameworks. So many libraries. Front end. Back end. Etc. But, we're still working within the paradigm of the stateless Web, designed to display documents and images. Trying to hammer an application in there (especially a SPA) really doesn't make sense. So, why do we just keep forcing it? If leveraging the ubiquity of the Web is the objective, then there's nothing to say we couldn't have a VM running in a browser that itself uses web protocols/languages, but abstracts them away. That would leave us writing code a la Swing, an event-driven, component-based model that makes so much more sense for a GUI style application. No CSS, HTML, fighting back-buttons, state management, routing, etc. That's all handled in the VM.
- pbourke 6y ago
  > So, why do we just keep forcing it? Because hyperlinked documents are the whole ball game. Web technologies are a pain in the ass for developers but a boon for the advancement of human knowledge and connectedness. The great islands and continents of web space float in the same aether. They interconnect, despite being built at different times, in different styles, on different technologies. It all just, for the most part, works. It’s fucking beautiful. The system is greater than the sum of its parts.
  - unclebucknasty 6y ago
    My comment was WRT to a better model for developing SPAs and complex Webapps, not sunsetting the Web in general.

joeberon 6y ago

Isn't this the same in almost any industry? For example, in engineering this kind of "reinventing the wheel ad infinitum" you are describing is incredibly common. How many times to you think engineers have separately designed and tested clips to hold capacitors in place in the ECU of a motor? Many thousands of times, while being paid competitive salaries. Maybe you should argue there should be some "book of capacitor clip designs" but actually this doesn't work in practise because every capacitor clip design needs to fulfil very slightly different requirements. Often it is just easier and faster to redesign from scratch. Taking existing components and redesigning them in some small way to fit your specific requirements is common in almost every industry I can think of.

dilandau 6y ago

Nice take. Yes design/frontend has rarely been about actual design. Backend web has rarely been about engineering either, I'd say. Just look at all the elastic search engines left open to the public internet as proof of unconscionable levels of ignorance.