Hacker News Reader

Comment by XCSme | Hacker News Reader

As an experienced front-end developer I must say that I don't really understand why the complexity of building websites is growing instead of going down. We have build thousands of front-end frameworks and all of them try to solve the same issues that should have been solved by the browsers themselves a long time ago. We implement complex "routers" and "server-side-rendering" to show specific content when the URL in the address matches a specific value, while the entire web architecture was made exactly for this purpose, to show some content when you go to an URL. Tens of years of "evolution" and we just keep making everything slower and more complex for no reason, apart from being bored or wanting to be trendy.

I know all those frameworks exist to solve a specific problem, but while doing so we are creating hundreds of problems that never existed before.

View on HN

Part of it is that the web platform itself can't evolve as fast as industry would like it to, so in the meantime we pull together/test out new features we'd like to see in JavaScript, until the web can implement them natively. Just look at jQuery: it was a proving ground for fetch(), document.querySelector(), and more. Now it's unnecessary.

Part of it I think is that we're still in a period of growing-pains. The web is transitioning from a document platform to an app platform, and until it fully catches up to that mandate, we have to bridge the gap with layers upon layers of frameworks. I think we're entering the downslope of that process, but it isn't finished.

That said, I do wonder why there isn't so much as a proposal for native HTML templating (the <template> tag doesn't count). This has been industry-standard practice for 5 years now and would benefit immensely from a native implementation. It seems like it's well past time to get that ball rolling.

> I do wonder why there isn't so much as a proposal for native HTML templating

There were XHTML with XLSTs. It was widely rejected, most people didn't even see the point.

We need a little more than that, though. You can accomplish that right now with JS template string literals and innerHTML:

  function myComponent(props) {
    return `
      <div>
        ${props.name}
      </div>
    `
  }

  ...

  document.body.innerHTML = myComponent({ name: "Bob" });

The problem is that it always completely obliterates the DOM, instead of changing just the parts that need to change. The browser, of course, has plenty of information with which to do that in C++ instead of requiring the use of something like React. But for some reason it hasn't been implemented.

You may be looking for morphdom, which is a very lightweight version of what you want, but of course browser support for this would be nice. https://github.com/patrick-steele-idem/morphdom

Lithtml implements declarative DOM using string literals like this very efficiently.

I'm of the opinion that sticking with React when Lithtml exists is just fear of writing vanilla classes.

That might be because XSLT was very hard to use. There were some XSLT processors, but none of them were in-browser or anything close to that. There were promises of browsers that would implement it, but AFAIK no browser really did. XSLT didn't have a simple syntax either. Looking at XSLT, it basically does what most templating engines do these days. But in a more complicated manner. Just look at Wikipedia's example [1].

About ease of use in programs, if you were using XSLT, you had to output XML which then had to be put through an XSLT processor. If you are outputting XML to another program or database or whatever anyway, that would be possible. But if you are only outputting XML so it can be transformed to XHTML by an XSLT processor, for which you had to write something in XSLT, you could just spare all the hassle and directly output HTML anyway.

[1]: https://en.wikipedia.org/wiki/XSLT#Examples

I am sorry but you are wrong about several technical issues regarding XSLT.

FF and IE had XSLT processors in 2006 and I suppose they still do (although could be wrong about the still do), there were at any rate XSLT processors in browsers back til the early years of this century, although hey, not in every browser. Opera was definitely dead set against ever implementing one.

You did not have to output XML, you could output XML, text, or html, depending on the output format the processor would handle how your output format should work (as it was a declarative language) thus if you output html the processor would handle turning XML like br elements into html br elements, not that that is any great thing, but it is a fact you could output other things than XML

Yes, I think the problem is in way the current web ecosystem is evolving. People notice shortcomings of current browsers, they create frameworks that add the needed functionality (usually in a really hacky way that adds a lot of complexity and creates new problems), browsers acknowledge the potential feature (... wait 5-10 years...) feature is implemented, said framework becomes redundant and everyone now has to learn a shiny new framework.

The saddest part is that the shortcoming that the initial framework tries to solve is, most of the times, insignificant compared to the complexity that the framework is adding.

The truth is that we are all just "play-testers". We keep mocking new browser features, put them in the real world, test them, and then browsers can easily decide what features really provide value and should be implemented.

The real problem is that this is a never-ending cycle. We started to like this creation of new features so much that we never really focus on what we have and try to make the most out of it. We keep adding bloat to fix imaginary problems, when we already have all the tools that we need. I am not referring to new functionality, such as Web Payments or OffscreenCanvas, but to frameworks that try to mimic what the browsers are doing and just do it in a slightly better way.

> The real problem is that this is a never-ending cycle.

That's where I disagree. I think the web was fundamentally unsuited to the "application" use-case and has been making its way in that direction for 5-10 years now. I think once we reach that destination, the churn will drop off dramatically. The platform will become enough, for the most part, and we may shrug off the need for comprehensive "frameworks" altogether in favor of simple libraries, like most other language ecosystems.

I do feel that the application use-case has already been reached, yet I do not think this cycle speed is going to change. I do hope that at some point this will stop as this cycle is wasting way too many human brain resources which could be otherwise used on more interesting problems.

> I do feel that the application use-case has already been reached

It clearly hasn't though, as demonstrated by this very OP ;)

Everything people are complaining about here, in addition to the problem being addressed by Concurrency Mode, are things that writers of native apps don't have to fight with:

- Lack of concurrency

- Complex, layered build systems

- Several layers of syntax transformation as an industry baseline

- Lack of a consistent story for modules

- Overall jank-proneness

- Platform bloat like that in Electron

But then why re-solve all these problems if you can just build a native app? Because native platforms over the decades have repeatedly tried and failed to a) be truly cross-platform and b) have truly flexible, well-documented layout systems. The web gives us those. We just have to go back in and add the things it lacks.

When all of these problems have been solved and a new framework is still coming out every week, then we can talk about frivolous effort being expended. Until then these are real, worthwhile problems being worked on.

I agree that native platforms have failed to give us the things that the web platform gives us, and that we want those things in our solutions, but it does not mean that we will ever actually be able to add in the things that the web lacks - I suppose that we will be able to but I must also entertain the possibility that there is some mutually contradictory thing in the two paradigms that we are not seeing.

>As an experienced front-end developer I must say that I don't really understand why the complexity of building websites is growing instead of going down.

Really? I think its pretty obvious that the complexity of websites (or really, web apps) is increasing every day. For the most part, web sites are not just static content any more. More devices, more users, more features for even the most basic types of sites lead to increased complexity of building something that meets those demands.

>We have build thousands of front-end frameworks and all of them try to solve the same issues that should have been solved by the browsers themselves a long time ago.

Sure, but they haven't been solved so do we just say to users "Nope, sorry, Chrome never implemented this so it's not possible"?

I can't help but think that this type of argument is based on an idealized version of the web where every website can be reduced a personal blog like the "good old days". The web has evolved, and so have users and what they expect from it.

I mean sure, if you are literally creating a personal blog - don't use React. But otherwise, I don't really get this POV.

We used to build very complex pre-ajax websites (iframes all the way) for the enterprise. So I can hear the author. It is not easier or cheaper or quicker to build and run and maintain exactly the same thing in 2019 (comparing to 2005) which also makes me wondering if the browser programming became the wheel invention exercise. Cmon, we dont have ie6 any more and you can actually debug js with the amazing tooling these days - solving browser quirks was the major PITA and time waster. So where the time goes now? Learning pecularities of a new fashionable framework which will be out of fashion in a few years.

I'm not sure if I can agree with you there. Do you really think it's more expensive and slower to build an app with the exact same functionality today than 10 years ago? 15?

I would instead argue that websites today tend to have far more features and functionality than their counterparts of 15 years ago.

I can't say for all the websites, sorry, just for my space.

> I don't really understand why the complexity of building websites is growing instead of going down.

People are doing things with websites they never did before. Office applictions, games, native-like UIs, real-time messaging, analytics and dashboarding, programming.

Good or bad, websites today have different interactions, behaviors, and development costs than 10 years ago. It sneaks up on you but if you see screenshots or use an old website you will immediately notice the difference.

> but while doing so we are creating hundreds of problems that never existed before.

Such is innovation.

> Tens of years of "evolution" and we just keep making everything slower and more complex for no reason, apart from being bored or wanting to be trendy.

Try making a website good enough that people will actually pay for it.

You may find your opinion changes.

I do agree that new features were needed for new functionalities, such as games or actual apps, but the irony makes it that we are discussing this on a site used by millions, a site which doesn't use all those fancy frameworks and features. I was mostly referring to the average site created today, be it either by devs or directly by clients using some CMS like WordPress.

Don't get me wrong, I actually used and love(d) React, but it feels like in the majority of cases the library is misued and people just create normal sites (that could have existed 15 years ago, but a loat bloatier) instead of creating the apps you were referring to.

> it feels like in the majority of cases the library is misued and people just create normal sites (that could have existed 15 years ago, but a loat bloatier) instead of creating the apps

So React shouldn't get new, powerful features because some people might (ab)use them for simple websites that don't need it? That's bollocks and I'm sure you can see that. If you are generally annoyed about this, go rant on Twitter - no reason to do it here.

> we are discussing this on a site used by millions, a site which doesn't use all those fancy frameworks and features.

I love HN as well, but this is a niche site for niche purpose.

These types of comments serve no purpose and really irritate me.

Either

A) You are ignoring that modern web apps are very complex w/ dashboards and complex flows that can't be modelled with a simple URL scheme.

B) You are saying "Actually I don't have a problem with React, my issue is with people using it everywhere for simple things". Which is silly because

1. That's not relevant to the article. Go talk about that issue somewhere else.

2. This feature is clearly only meant for more complex React applications, so you don't need to worry about it "over-complicating" simple React apps.

3. This feature would be just as hard to implement in a traditional web-app. JQuery based web-apps aren't simple, they are imperative hellholes.

4. React makes "simple" web-apps simpler. Even for websites that don't need React, using it can make the dev process easier.

>You are ignoring that modern web apps are very complex w/ dashboards and complex flows that can't be modelled with a simple URL scheme.

...the problem here is developers consistently try and shape the round hole to fit their square peg. Web apps are not the appropriate product for this design problem - the solutions are desktop applications.

It's very unfortunate that the ecosystem is so hostile to traditional desktop apps and solutions, but that gets back to OP's point - these frameworks are solving problems we've manufactured.

In 2004 I had a small company with some friends and we were making a desktop app that we called a media management system, that was basically for managing generating multiple media outputs from single sourced data yadda yadda yadda (I could go more into it), anyway we had some interest and some sales but we ended up running out of money and going bankrupt. I remember there were some interested people that would have thrown us money to keep going longer - but they really thought we should have been a web based application.

So if by ecosystem you mean money, yeah, but I only make web apps nowadays unless someone comes with a big bucket of money for the desktop app beforehand - which I never see happening for some reason.

When you get down to it, the web is fantastic at displaying information not stored on a user's machine. It's also pretty good at taking user information and moving it somewhere else.

But if your product is not just about information retrieval or collection, rather based on things like complex user interaction, persistent local data storage, integration with devices on the users machine or complex interactions that need to override mouse/keystroke behavior... then I'd question whether or not it should be a webapp.

Discord is a really good example of this to me. They have a web client, sure, but the app itself makes sense on the desktop. There's nothing wrong with using web technologies to build the app, but the mental model of how browsers send/receive data from a server somewhere seems fundamentally incompatible with how such an app should work.

What I meant by hostile is that publishing apps sucks for a lot of reasons, from lack of user demand to platform issues, poor sandboxing, distribution issues, etc. It's a shame, because that's how we wind up with such crazy complexity in web apps, when we could just stick to native OS APIs and call it a day.

> There's nothing wrong with using web technologies to build the app, but the mental model of how browsers send/receive data from a server somewhere seems fundamentally incompatible with how such an app should work.

So the solution would be to exclusively some "web technologies" (HTTPS, WS) to deliver content and messages to the application? I guess by creating a bunch of clients, managing request states and working around the intricacies involved there (or in the libraries you used).

So after that's done then lets add some kind of auto-updating mechanism. After a while you get it working, awesome. Lets hope users constantly keep it updated! Spoiler: they will not.

And then, when you think you're all finished, someone from product comes in and says "hey we want to A/B test this feature on these specific clients, when it's a Tuesday and they are connecting from India. Oh and these requirements will change every 24 hours". Great.

"If only there was some set of technologies that made all of these problems convenient and effective", you think to yourself as you check Slack.

so you'd like for us to go back to QT and such instead of taking advantage of the benefits a model like React has already given us for cross-platform UIs? (correct and performant web, desktop, mobile UIs)

Whether web apps are technically the right-shaped peg for a given hole is not the only factor in what technology gets used, and usually not even the biggest one. More often than not, web apps make good business sense, so that's what gets built.

Regardless of where the problem came from, we still have to solve it.

Have to reviewed how multi-platform desktop apps are developed? Is that really easier and more elegant?

I have no idea why you have to resort to a traditional desktop application just because you want a way to show a loading bar... while something loads.

You likely don't have the problems that Facebook is trying to resolve with React.

Namely, developing something once and having it work ideally everywhere on the planet (slow network vs. fast network).

They're worried about shaving kilobytes here and there - concurrent mode helps to dynamically render/load items in an order that makes sense for people on slow networks where it wouldn't even matter for people on fast networks.

You likely don't have the problems that Facebook is trying to resolve with React.

Namely, developing something once and having it work ideally everywhere on the planet (slow network vs. fast network).

Providing users with the best experience possible in their browser regardless of the limitations of their computer and network is a problem every front end developer should be trying to solve.

Very few of us work at the scale of Facebook, but that particular problem isn't a scaling issue.

Suggesting we can ignore the problem of a bad experience for users on slow networks just because we operate at a smaller scale is plain wrong, and anyone making web tech with that attitude is failing the people who have to use the code they write.

Agreed. That's why I'm really happy with concurrent mode making this complex problem a little simpler to solve.

> Facebook is trying to resolve with React

You mean like being able to have juniors up and running and writing legible and maintainable (if at the cost of being opinionated) code?

As somebody that's helped teach HTML, CSS, JavaScript, and Python to dozens of brand new developers, React seems to help juniors move faster than ever, IMO.

And this is fine but why the facebook-scale problems solver becomes a mainstream library then? How many companies have these problems?

This is how things have worked in tech for at least the last 10 years (which is when I first noticed it). People that don't have the same problems as FAANGs cargo culting FAANG tech because it works for FAANG.

Because React's mental model and ecosystem makes a lot of developers happy regardless of not leveraging the more advanced aspects of both.

I've seen forms of this argument (essentially "you don't have the same problems Facebook has") more-or-less since I first started using React over 5 years ago, and it's never held that much water with me.

Mainly because I've only ever worked in comparatively small companies (fewer than 30 engineers) and every step of the way React has uncannily been solving the problems I've been facing (in fact, my decision to try React came at the end of months of trying alternative solutions to view layers until deciding to bite the bullet and try that weird JSX thing).

For me it comes down to a simple question: Is what you're doing sufficiently app-y to justify an up front framework cost of around 70kb (React + your ecosystem libraries of choice)?

If the answer is "no", there's a follow-up question of "is that likely to change within a year?"

It's relatively frustrating that React is one of the largest React-like frameworks (e.g. compared to Preact and Vue), but they've mostly been focused on different problems for the last few years. I'd expect React to get smaller and faster once there's less of a focus on fundamentally changing and simplifying the way we approach certain types of problems (e.g. the ones that Suspense solves).

Er this ended up being longer than expected, sorry about that!

No worries! It sounds like you're saying you haven't needed to tackle this problem, but React has solved tons of other problems for you.

> As an experienced front-end developer I must say that I don't really understand why the complexity of building websites is growing instead of going down.

Complexity of building dynamic documents is actually going down. If you are to build a typical web site from 200x using modern browsers, you wont need jquery or anything like that. Networking, security - everything became 100 times easier and faster.

But if you want to build a desktop application using DOM as a rendering layer, then it is a different story.

I challenge anyone who believes "the complexity building websites is growing" to go ahead and build a web app relying on multiple complex state machines with imperative jQuery calls, and then tell me it's less complex than the equivalent in React.

The complexity comes from getting the tooling installed now and packages.

If I can't just include a file things are going to get more complex.

State machines are a method to solve a problem that could be expressed in other ways to make it fit the language better.

What is complex about the tooling?

If I want to implement a rich text editor in my website, it will be as easy as 'npm install ...' and an import statement in the relevant file.

Is there an advantage to make a state machine to solve this?

> If I can't just include a file things are going to get more complex.

But the tooling and npm packages are all optional. You can import React from a CDN and use stuff like htm [1] or domz [2] instead of a JSX compilation step.

Or you can use Vue instead of React (their tutorial starts by using Vue via CDN).

If you're able to only support 95% of the browsers, you can use most modern ES6 features, including ES Modules and async/await.

If you still need the tooling, there are options like Parcel [3] or Poi.js [4] that require zero configuration. You don't really need the complexity of Webpack.

[1] https://www.npmjs.com/package/htm

[2] https://www.npmjs.com/package/domz

[3] https://www.npmjs.com/package/parcel

[4] https://www.npmjs.com/package/poi

I've used vue by including it. I've used react by including it and babel.

When I tried to include other packages they were only available through npm (some had cdn versions but most did not). You don't get access to the entire ecosystem without the tooling.

You can use a site like https://unpkg.com/ to include files from most npm packages using a script tag.

It's all a spectrum, but generally speaking, Web Frameworks are for Apps (Gmail, Facebook Ads Manager, etc.) and HTML/CSS sites are more for presentational pages, etc. The big problems come about when you try to cross those bounds.

At the extremes, you either end up with thousands of lines of spaghetti code or an over-engineered mess serving up a html page with a single image on it.

Web frameworks are just a tool that needs applied to the right job.

We're only really just beginning to use the full power of the browser... JS frameworks were often too fragile to scale up in size. Much like Vue's changes in v3, these frameworks are now solving these growing pains that come with truely large frontends. ...stuff that goes far beyond just the odd select2 widgets and autocomplete to be a core part of the whole app.

I partially blame the availability of large amounts of bandwidth in many portions of the world. We went from having strict data needs, where websites had to be crafted to be quick and clean, to now where just unoptimized and bulky JS litters the landscape.

I miss the old internet some days.

you mean the days when most software had to be manually installed on your Windows? :-)

Yeah, web is not only about documents these days (how it was originally intended) but it is also about running and hosting real-time applications.

But I hear you, people indeed use wrong technology to solve their problems. I agree that there is no need to use any React and Angular to display a document.

> you mean the days when most software had to be manually installed on your Windows? :-)

Oof I do not miss that! You are 100% correct that tool selection is a major decision in how well a product, app, or website responds. Perhaps we need more of that then?

That's how an app works now. Here is a program to do something external to the browser.

I feel like the amount of knowledge required is definitely going up, but once you have that knowledge I'm not sure it is necessarily more complex to make an app nowadays, like would you rather use jQuery, HTML templates, plain CSS files...?

For some cases yes, why not?

I went back to jQuery for a project because of windows 10 and webpack 2 issues.

I found it extremely easy to jump back into and high productive. I feel like the next generation will rediscover the simple nature of include a file.

Reply on news.ycombinator.com