6 ms·

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 hav

by XCSme 7y ago

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.

kylemh 7y ago
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.
- onion2k 7y ago
  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.
  - kylemh 7y ago
    Agreed. That's why I'm really happy with concurrent mode making this complex problem a little simpler to solve.
- dnautics 7y ago
  > 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?
  - kylemh 7y ago
    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.
- democracy 7y ago
  And this is fine but why the facebook-scale problems solver becomes a mainstream library then? How many companies have these problems?
  - bcrosby95 7y ago
    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.
  - kylemh 7y ago
    Because React's mental model and ecosystem makes a lot of developers happy regardless of not leveraging the more advanced aspects of both.
- andrewingram 7y ago
  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!
  - kylemh 7y ago
    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.
_bxg1 7y ago
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.
- marcosdumay 7y ago
  > 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.
  - _bxg1 7y ago
    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.
    - dnautics 7y ago
      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 https://github.com/patrick-steele-idem/morphdom
urda 7y ago
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.
- player2121 7y ago
  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.
  - urda 7y ago
    > 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?
  - wolco 7y ago
    That's how an app works now. Here is a program to do something external to the browser.
michaelbuckbee 7y ago
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.
protonimitate 7y ago
>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.
- democracy 7y ago
  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.
  - pythonaut_16 7y ago
    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.
    - 7y ago
fabiospampinato 7y ago
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...?
- democracy 7y ago
  For some cases yes, why not?
- wolco 7y ago
  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.
paulddraper 7y ago
> 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.
- XCSme 7y ago
  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.
  - sqren 7y ago
    > 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.
  - paulddraper 7y ago
    > 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.
player2121 7y ago
> 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.
- koboll 7y ago
  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.
  - wolco 7y ago
    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.
    - woat 7y ago
      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?
    - ratww 7y ago
      > 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 https://www.npmjs.com/package/htm [2] https://www.npmjs.com/package/domz https://www.npmjs.com/package/domz [3] https://www.npmjs.com/package/parcel https://www.npmjs.com/package/parcel [4] https://www.npmjs.com/package/poi https://www.npmjs.com/package/poi
dmix 7y ago
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.
marmada 7y ago
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.
- unlinked_dll 7y ago
  >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.
  - bryanrasmussen 7y ago
    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.

by XCSme 7y ago

kylemh 7y ago

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.

onion2k 7y ago
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.
- kylemh 7y ago
  Agreed. That's why I'm really happy with concurrent mode making this complex problem a little simpler to solve.
dnautics 7y ago
> 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?
- kylemh 7y ago
  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.
democracy 7y ago
And this is fine but why the facebook-scale problems solver becomes a mainstream library then? How many companies have these problems?
- bcrosby95 7y ago
  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.
- kylemh 7y ago
  Because React's mental model and ecosystem makes a lot of developers happy regardless of not leveraging the more advanced aspects of both.
andrewingram 7y ago
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!
- kylemh 7y ago
  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.

_bxg1 7y ago

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.

marcosdumay 7y ago
> 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.
- _bxg1 7y ago
  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.
  - dnautics 7y ago
    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 https://github.com/patrick-steele-idem/morphdom

urda 7y ago

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.

player2121 7y ago
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.
- urda 7y ago
  > 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?
- wolco 7y ago
  That's how an app works now. Here is a program to do something external to the browser.

michaelbuckbee 7y ago

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.

protonimitate 7y ago

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

democracy 7y ago
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.
- pythonaut_16 7y ago
  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.
  - 7y ago

fabiospampinato 7y ago

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

democracy 7y ago
For some cases yes, why not?
wolco 7y ago
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.

paulddraper 7y ago

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

XCSme 7y ago
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.
- sqren 7y ago
  > 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.
- paulddraper 7y ago
  > 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.

player2121 7y ago

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

koboll 7y ago
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.
- wolco 7y ago
  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.
  - woat 7y ago
    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?
  - ratww 7y ago
    > 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 https://www.npmjs.com/package/htm [2] https://www.npmjs.com/package/domz https://www.npmjs.com/package/domz [3] https://www.npmjs.com/package/parcel https://www.npmjs.com/package/parcel [4] https://www.npmjs.com/package/poi https://www.npmjs.com/package/poi

dmix 7y ago

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.

marmada 7y ago

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.

unlinked_dll 7y ago
>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.
- bryanrasmussen 7y ago
  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.