Hacker News Reader

> 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.

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.

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.

>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.

I suppose another way of looking at it, is more about what you've mentioned with Stripe, Braintree, etc. A lot of the things that a web business needs to run are getting built out as APIs. At some point, I predict non-tech companies that still need some tech components, they will:

  * pick out the SaaS they need, and someone will write a tool to integrate the top different SaaS providers together
  * they will differentiate themselves from their competitors based on their product offering and branding, less so on tech

So, I'm not saying that programmers in general will be able to plug and play backend infra like Legos, but that non-technical people will be able to mix and match the infra components they need without doing coding. For these kinds of people, what the computers are doing is not important, and the frontend is more important, IMO.

It might be possible that product development itself is the actual bike shedding, and all the frontend, backend and product devs help the product owner realize that ;) However, you can't know in advance, yet the process has a tendency to self correct over time - creative destruction and all that.

> the process has a tendency to self correct over time - creative destruction and all that

I wonder how long it takes for the correction to kick in, because for the last decade+, software seems to be getting worse and worse - slower, bloatier, less functional, and with more user-hostile business models.

Just look around your government systems. They have had decades to fix themselves but are they fixed yet? Are they faster, less bloatier, less user hostile and privacy invasive?

Let’s hope the public sector isn’t the model that the software industry is following.

Why, but it is. It's not the public sector that's causing these problems, it's the private companies that fulfill government contracts.

It seems that each generation of programmers at some point comes to this epiphany that a lot of things that they're doing are repetitive enough that they ought to be doable by non-programmers, if you just come up with a way to glue those common things together easily. That was the story behind "4th generation" programming languages, for example; and to some extent, behind RAD.

Every attempt so far produced many technologies that died very fast, and a few (e.g. SQL) that survived long enough to become a natural and useful part of the landscape - but even that part still requires programmers to tend to it. When non-programmers try to use that tooling, the result rarely works well; and in those few cases when it does, it's rarely maintainable anyway.

RAD died because it could only cover 98% of business needs and idiot managers thought they needed a language to deal with 100% and so threw away really great tools.

I could fully foresee VB making a comeback in the future.

RAD never really died, we just stopped calling it that.

But open Visual Studio today, and create a new Windows XAML app, then open the form designer. You can still drag a button from the toolbox, move it around, then double-click it to wire up an event handler - exactly like it was in VB6. In fact, it's quite possible to ignore all the modern stuff like data bindings entirely, and just manually read and update all widgets, as a typical VB/Delphi app did.

A typical Delphi app might have done that, but a selling point of Delphi was that it had data binding.

Connect the TDB* vies to a TDataSource, and it would show the values of a database, without requiring manual updates.

VB6 and WinForms also had data binding. But in practice I've rarely seen it used, except for data grids.

WPF has databinding available today, it's not gone away.

https://docs.microsoft.com/en-us/dotnet/desktop-wpf/data/dat...

For WPF, data binding is idiomatic. It wasn't back in those days.

My point is basically that the tooling that we use for desktop UI development is still very much rooted in the RAD era - but as best practices around it changed, we dropped the "RAD" label. It was a gradual evolution, though.

Don't be shy, go that last extra mile and just say that frontend engineers are fraud.

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.)

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.

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.

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.

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.

Using web technologies is not the same as doing crud web apps. Games for example are a very different kind of programming. And even if network admin and factory automation apps have web front-ends, that's still a minuscule part of the code.

Games are very different programming. Code surrounding games - lobby, game server lists, marketpaces, IAP - this is pure CRUD, and it's entirely unrelated to the game code.

I think there's a strong overtone of that in many places, including in business and popular culture. Most peoples' interactions with software are phone apps and web fluff.

Does the majority of software lie elsewhere?

Type "developer" into a job search.

The majority of all software in the world actually does lie in CRUD web apps today.

<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>

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.

> 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.

My comment was WRT to a better model for developing SPAs and complex Webapps, not sunsetting the Web in general.

I'm personally curious how far we could go with using just canvas and wasm. If we focused on making a browser that was just incredibly efficient and focused at using wasm and webgl, and had no other concerns, a lot of the cruft could be cut. Then any given "page" would essentially just expose the canvas for wasm to draw to, and GUI frameworks like Qt (which already can compile to wasm I believe) could just target this. We could then have different UI toolkits targetting this model, and hopefully even have something akin to Flash without being the same security nightmare.

Keep the current browser stack for the things it still makes sense for - static content like articles and blogs, and forums too, but anything with greater complexity and reactivity would run faster and get better gains from just abandoning html/js completely, and browsers themselves could stem the unending march of feature creep.

I'm just spitballing here, I'm not sure I think this is actually a good idea - you'd be losing a lot of accessibility you get for free with HTML for example, but I'd like to see some experiments in this area to see how far this could go.

We should embrace flash again - https://github.com/ruffle-rs/ruffle

> I'm personally curious how far we could go with using just canvas and wasm

In a word: accessibility. HTML is inherently accessible - you can curl a webpage and read the contents of any (static) web page. If you curl an entirely <canvas> based web page, you'll walk away knowing only that the web page has a <canvas> element in it.

You mentioned Qt. I've never programmed a Qt app, but I went hunting for its accessibility features in the docs[1]. I'm encouraged that Qt takes accessibility and Assistive Technologies seriously. However, if you're coding a web page in canvas/wasm/Qt you're going to need to make sure all the content, links and additional accessibility/AT requirements get ported from the <canvas> into the surrounding DOM to make it accessible.

That's a huge amount of work!

[1] - https://doc.qt.io/qt-5/accessible.html

Yes, the Web should stay what it is for static documents. In fact, what I advocated would continue to be based on Web standards (HTML, CSS, Javascript, and newer constructs like canvases, etc).

So, you would have a JS-based VM that runs in the browser. No Flash or other binary. Just pure Web standards for executing the code, rendering, etc. However, as an app developer, you wouldn't touch HTML or Web standards. Instead, they'd all be abstracted away and you'd work within a component/event driven model that's provided by the VM.

Instead of CSS, you'd roll themes, allowing you to stylize components. They'd ultimately be applied via CSS, but ideally you'd have a GUI interface for creating these themes. CSS gives you ultimate flexibility, but why are we still fighting whitespace and these other low-level document layout constructs when we are really working at a UI component/control level? It's like designing in assembly.

Instinctively, people won't want to give up this granular control. But that's only because we've been thinking about apps in Web terms for so long.

For me, that's the problem with a lot of these frameworks. They do a great job of helping you to wrangle the impedance mismatch between the web and apps. But, they are all predicated on deference to the Web, so they keep us immersed in this world, essentially fighting the Web's ill-fittedness to the task: HTML templates, DOM management, render functions with HTML strings, CSS styling embedded in "components", etc.

Why go so far to create a framework only to hamstring it with the very problems it aims to solve?

I agree, I feel like all the points both for and against SPAs and frontend frameworks in this thread are just circling around the idea that browsers make an awful platform for building software. But the delivery mechanism is so much more compelling than anything else available, and the momentum so great, that we're all willing to put up with it.

It will never happen, but I wish there was a second stack that browsers understood, totally separate from the DOM, purpose built for developing _applications_, rather than abusing the fact that this document creation tool allows us to put styled boxes in different places.

This is not really a failing of HTML, CSS, or JavaScript, but if your platform SDK's total feature set for building UIs amounted to some basic form inputs, incredibly inflexible tables, and a handful of ways to add semantics to otherwise featureless blocks of text and boxes, you'd be laughed out of the room. The fact that anything remotely feature rich must be built from scratch is part of the reason the ecosystem has such a bad rap for over reliance on packages, and for constantly reinventing the wheel.

Well, and this is it, isn't it?

The whole conversation ignores, for example, the reason that jQuery was invented: At a time when there were many competing browsers, all of which spoke different dialects of JavaScript (that's my punny way of saying that they had different bugs), HTML/CSS bugs that were all different across browsers... jQuery brought order to chaos.

And the problem is, that as browsers improved and got closer to general standards compliance (where we STILL ARE NOT today), they didn't remove the cruft and the past bad behavior - no, they continue to support code that implements that crappy API that was deprecated 15 years ago.

These problems continue today and as long as that is true - as long as fundamentally, the problem is the browser itself -- these frameworks will continue to have a place.

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.

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.

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.

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.

Low code and no-code markets are growing rapidly, so don't be sure the markets have decided.

"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?

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.