6 ms·

Is is really that bad? I'm not very up-to-date with JS frameworks, so please bear with me. I know that new libraries pop up here and there, but if I'm not wron

Is is really that bad? I'm not very up-to-date with JS frameworks, so please bear with me. I know that new libraries pop up here and there, but if I'm not wrong, React is by far the most popular, and React has been around for almost 10 years. Vue's not much younger, and now it's 3rd major version. Is there such a big difference between JS front-end frameworks and the rest of the world?

EMM_386 5y ago
> Is is really that bad? It's not that bad. I am lead on a large Angular 13 project and we love it, easy to work with, build, deploy. We have literally no issues at the moment. .Net 6 C# APIs on the back-end, Oracle database. It just works. Take everything with a grain of salt.
- oblio 5y ago
  How is internationalization? Last I asked, it was still a tire fire, even after more than a dozen versions and after a fully mature previous framework that was replaced :-(
  - FinalBriefing 5y ago
    Yea...Angular made a huge (and hardly documented) change to their internationalization library that forced us to migrate to a third-party one. Basically, they now (as of Angular 12) force you to build a difference version of your app for each language you support, and either serve them up at different URLs or use cookies to serve up the right version to each user. The technical reasons make sense...your translations occur at build-time, rather than at run-time, but it's a pretty drastic change that occurred out of nowhere. Not a fan.
    - ipaddr 5y ago
      Hardcoding a language variable into multiple builds?
    - tlrobinson 5y ago
      Are you required to use Angular’s i18n support for some reason? I use ttag (https://ttag.js.org https://ttag.js.org) with React and like it. I don’t see any reason you couldn’t use it (or another library) with Angular.
      - oblio 5y ago
        Angular tries to be a 1 stop shop and internationalization is a major feature.
        tlrobinson 5y ago
        That doesn’t necessarily mean you have to use it.
  - deleted 5y ago
    [deleted]
- Alex3917 5y ago
  I feel the same way about Angular. There some minor bugs that have had open issues for 5+ years and may well never get fixed, but by and large the day-to-day experience of writing and maintaining code is pretty great. I just don't get the concept of people being like, I'm going to start a project that's likely going to take the ten years to become successful, but I'm not willing to spend the twenty hours to read the documentation so that it will be successful.
- pier25 5y ago
  As a user, big Angular apps feel super slow and bloated. Eg: Google Cloud console downloads like 20MB of resources. Maybe the DX is good, but from an end user perspective, Angular is far from good.
  - EMM_386 5y ago
    > Eg: Google Cloud console downloads like 20MB of resources. That must be a fairly large application. Consider they are pushing it internally, I have no idea how optimized that is. When you consider this is cached, that means you only have to do that once until an update. Similar to any other software. Look at what Electron apps do in terms of constant updates. This is similar, but it's a web page.
    - pier25 5y ago
      This is just on first page you load. As you navigate it loads a LOT more more stuff. I opened the console and it loaded like 20MB, then I navigated to another section and it loaded 15MB more. And the problem is not only the bytes loaded but how clunky and slow it is in general. The Electron argument doesn't make any sense as it includes two runtimes ffs.
  - Alex3917 5y ago
    > Google Cloud console downloads like 20MB of resources. That's literally the biggest (publicly known) Angular app in existence, and the fact that it's slow doesn't have anything to do with Angular. E.g. FWD:Everyone pages load in well under half a second: https://www.fwdeveryone.com/t/K3KKGbMyQbaCGDc-izuaow/venmo-frozen-account https://www.fwdeveryone.com/t/K3KKGbMyQbaCGDc-izuaow/venmo-f... At this point the main things preventing it from being faster are the TTFB from CloudFront, and the fact that Bootstrap is used as a dependency.
svachalek 5y ago
Things were really a mess for a while, maybe 6-7 years ago. Nothing was compatible with anything else, even itself from last month. But nowadays things are pretty stable, if you stay away from the hotness of the month which will be forgotten next month.
bussyfumes 5y ago
I think it’s a bit of an outdated stereotype from back in the day when this kind of frameworks started popping up left and right. It was a major shift from jquery-based sites/apps which scared many people away from diving deeper into front end. Nowadays you can stick to one of the major three and you’ll be fine for the foreseeable future. This new Vue version is the most disruptive change we’ve had since a long time ago in the fe framework space and it’s still ok to get used to.
- FinalBriefing 5y ago
  Yea, most of my Vue 3 components look just like my Vue 2 components (which look a lot like Vue 1 components). Really easy transition for devs.
qbasic_forever 5y ago
I think a lot of people got a bad taste from webpack, gulp, etc. projects ~5 years ago that immediately mired you in deep config complexity to do anything. Nowadays there's a lot more documentation and emphasis on zero config / convention / CLI tooling to remove a lot of that complexity. Things are a lot better nowadays, especially if you're doing something greenfield and can use the latest tooling like vite, esbuild, etc.
- deleted 5y ago
  [deleted]
- e12e 5y ago
  >... especially if you're doing something greenfield and can use the latest tooling like vite, esbuild, etc. Well, kinda? I tried to set up typescript, storyboard and tailwind the other day, via create-react-app - and it's not really clear if I can/should use npm or yarn, and what, if any bundles like webpack or esbuild/craco I need... Nor did any of the documentation/tutorials "just work" - and as final punishment I think I had to download more than a gig of dependencies. I get that there are many layers of tooling, but when I can't seem to get half the features of qt, nor a gui for 4gl development - it does seem like there's a lot of churn and pain for limited gain.
  - ipaddr 5y ago
    Here is advice. Using Laravel with Breeze and the set up just works out of the box.
    - e12e 5y ago
      Appreciated, even if it's not a good match for our other tech for most of these projects. That aside, do I then get Storybook and an easy way to integrate with tailwinduikit?
grayrest 5y ago
The ecosystem largely settled out in 2014 when everybody was "javascript fatigue" complaining. The developments since have mostly been refinements on details of the development setup or state management. There's new stuff but I'm pretty sure anybody who wrote React at the time would be comfortable with the slight modifications in the patterns of how things fit together. We're kind of into the next generation of frameworks (Solid, Svelte 3, Vue 3) and that's more about how much JS is getting delivered to the client. The current area of exploration is "partial hydration" where the goal is to write stuff using the component model but do server rendering and only send JS for the parts of the page that'll change client side. For quite a few classes of application this would substantially reduce the size of JS over the wire. All this is less of a benefit than the state control React brought so I expect slower/partial adoption. More broadly, there's been a resurgence of the render everything on the server and send html diffs approach in the form of alpine and htmx. The other potential area for change on the horizon is web assembly getting host bindings support so it doesn't have to bridge through JS to affect the DOM and other browser APIs.
- arnvald 5y ago
  Thanks for a thorough explanation! I've heard about NextJS, NuxtJS etc. and I know they're built on top of React and Vue, but didn't really know what kind of value they provided, now that's clearer.
- xdennis 5y ago
  I'm not sure about that. 2014 is when Webpack was released and React was released the year prior. Maybe one or two years after that.
armchairhacker 5y ago
Honestly if anything, web frameworks are way ahead of the rest of the world. The real difficulty is that web UIs have to be very flexible and varied: you have different screen sizes, mobile vs desktop, and every website has a different UI vs native apps all looking similar. And yeah, there are over 100 different web frameworks most which have a particular use case, although you don't have to use the perfect tool for the job. Also, there are a few quirks left over from the old days of HTML/CSS/JavaScript. But making a basic website nowadays on modern tools is very straightforward. Clone a vite starter project, write out your DOM in React or Vue or Svelte or Solid.js or whatever, and launch a live-server with a browser inspector to fine-tune the design. There are some especially bad JS frameworks (looking at you Meteor), but that's the case for most platforms.
- wruza 5y ago
  Honestly if anything, web frameworks are way ahead of the rest of the world Made me chuckle. Web frameworks are thin-to-medium layers of dealing with bs that web graphics are by nature and design. Their entire purpose orbits around that. Runtimes that do not suffer from these birth traumas don’t even need all that complexity. E.g. with apple core ui libraries you can in hours design a new flex/grid/stack/align/etc geometry container (which takes decades in the web), can animate things, make them cheap-scrollable, sizeable, constrainable out of box. Do you really think that web reflows and size dispatch up and down a hierarchy is a complex issue which only a “top-notch” web tech can solve? Of course web traditionally was more game-like and does not have any guidelines and presentation standards beyond “reset”, allowing to focus on design better than the rest of the world (and due to widespread nature monopolized by a single platform), but calling frameworks which basically deal with its own shortcomings and ancient issues ahead of the world is pretty misleading. What exactly is ahead of the world in there? My bet is on reactivity, components, caching and lazy redraws, which “weren’t a thing” before web, because, you know, jquery and comctl32.dll were bad. making a basic website nowadays on modern tools is very straightforward … and launch a live-server with a browser inspector to fine-tune the design Ah yes, something we had at VB/Delphi 3 times but not quite as RAD. I mean, maybe launch a live server, drop a query and see live data in design-mode, or enumerate columns and make some of them editable out of box? Or fill a form with master-detail link? You can’t. Web praises primitive/workaround things which nobody even had a name for before, so trivial and obvious and default it was.

EMM_386 5y ago

> Is is really that bad? It's not that bad. I am lead on a large Angular 13 project and we love it, easy to work with, build, deploy. We have literally no issues at the moment. .Net 6 C# APIs on the back-end, Oracle database. It just works. Take everything with a grain of salt.

oblio 5y ago
How is internationalization? Last I asked, it was still a tire fire, even after more than a dozen versions and after a fully mature previous framework that was replaced :-(
- FinalBriefing 5y ago
  Yea...Angular made a huge (and hardly documented) change to their internationalization library that forced us to migrate to a third-party one. Basically, they now (as of Angular 12) force you to build a difference version of your app for each language you support, and either serve them up at different URLs or use cookies to serve up the right version to each user. The technical reasons make sense...your translations occur at build-time, rather than at run-time, but it's a pretty drastic change that occurred out of nowhere. Not a fan.
  - ipaddr 5y ago
    Hardcoding a language variable into multiple builds?
  - tlrobinson 5y ago
    Are you required to use Angular’s i18n support for some reason? I use ttag (https://ttag.js.org https://ttag.js.org) with React and like it. I don’t see any reason you couldn’t use it (or another library) with Angular.
    - oblio 5y ago
      Angular tries to be a 1 stop shop and internationalization is a major feature.
      - tlrobinson 5y ago
        That doesn’t necessarily mean you have to use it.
- deleted 5y ago
  [deleted]
Alex3917 5y ago
I feel the same way about Angular. There some minor bugs that have had open issues for 5+ years and may well never get fixed, but by and large the day-to-day experience of writing and maintaining code is pretty great. I just don't get the concept of people being like, I'm going to start a project that's likely going to take the ten years to become successful, but I'm not willing to spend the twenty hours to read the documentation so that it will be successful.
pier25 5y ago
As a user, big Angular apps feel super slow and bloated. Eg: Google Cloud console downloads like 20MB of resources. Maybe the DX is good, but from an end user perspective, Angular is far from good.
- EMM_386 5y ago
  > Eg: Google Cloud console downloads like 20MB of resources. That must be a fairly large application. Consider they are pushing it internally, I have no idea how optimized that is. When you consider this is cached, that means you only have to do that once until an update. Similar to any other software. Look at what Electron apps do in terms of constant updates. This is similar, but it's a web page.
  - pier25 5y ago
    This is just on first page you load. As you navigate it loads a LOT more more stuff. I opened the console and it loaded like 20MB, then I navigated to another section and it loaded 15MB more. And the problem is not only the bytes loaded but how clunky and slow it is in general. The Electron argument doesn't make any sense as it includes two runtimes ffs.
- Alex3917 5y ago
  > Google Cloud console downloads like 20MB of resources. That's literally the biggest (publicly known) Angular app in existence, and the fact that it's slow doesn't have anything to do with Angular. E.g. FWD:Everyone pages load in well under half a second: https://www.fwdeveryone.com/t/K3KKGbMyQbaCGDc-izuaow/venmo-frozen-account https://www.fwdeveryone.com/t/K3KKGbMyQbaCGDc-izuaow/venmo-f... At this point the main things preventing it from being faster are the TTFB from CloudFront, and the fact that Bootstrap is used as a dependency.

svachalek 5y ago

Things were really a mess for a while, maybe 6-7 years ago. Nothing was compatible with anything else, even itself from last month. But nowadays things are pretty stable, if you stay away from the hotness of the month which will be forgotten next month.

bussyfumes 5y ago

I think it’s a bit of an outdated stereotype from back in the day when this kind of frameworks started popping up left and right. It was a major shift from jquery-based sites/apps which scared many people away from diving deeper into front end. Nowadays you can stick to one of the major three and you’ll be fine for the foreseeable future. This new Vue version is the most disruptive change we’ve had since a long time ago in the fe framework space and it’s still ok to get used to.

FinalBriefing 5y ago
Yea, most of my Vue 3 components look just like my Vue 2 components (which look a lot like Vue 1 components). Really easy transition for devs.

qbasic_forever 5y ago

I think a lot of people got a bad taste from webpack, gulp, etc. projects ~5 years ago that immediately mired you in deep config complexity to do anything. Nowadays there's a lot more documentation and emphasis on zero config / convention / CLI tooling to remove a lot of that complexity. Things are a lot better nowadays, especially if you're doing something greenfield and can use the latest tooling like vite, esbuild, etc.

deleted 5y ago
[deleted]
e12e 5y ago
>... especially if you're doing something greenfield and can use the latest tooling like vite, esbuild, etc. Well, kinda? I tried to set up typescript, storyboard and tailwind the other day, via create-react-app - and it's not really clear if I can/should use npm or yarn, and what, if any bundles like webpack or esbuild/craco I need... Nor did any of the documentation/tutorials "just work" - and as final punishment I think I had to download more than a gig of dependencies. I get that there are many layers of tooling, but when I can't seem to get half the features of qt, nor a gui for 4gl development - it does seem like there's a lot of churn and pain for limited gain.
- ipaddr 5y ago
  Here is advice. Using Laravel with Breeze and the set up just works out of the box.
  - e12e 5y ago
    Appreciated, even if it's not a good match for our other tech for most of these projects. That aside, do I then get Storybook and an easy way to integrate with tailwinduikit?

grayrest 5y ago

The ecosystem largely settled out in 2014 when everybody was "javascript fatigue" complaining. The developments since have mostly been refinements on details of the development setup or state management. There's new stuff but I'm pretty sure anybody who wrote React at the time would be comfortable with the slight modifications in the patterns of how things fit together. We're kind of into the next generation of frameworks (Solid, Svelte 3, Vue 3) and that's more about how much JS is getting delivered to the client. The current area of exploration is "partial hydration" where the goal is to write stuff using the component model but do server rendering and only send JS for the parts of the page that'll change client side. For quite a few classes of application this would substantially reduce the size of JS over the wire. All this is less of a benefit than the state control React brought so I expect slower/partial adoption. More broadly, there's been a resurgence of the render everything on the server and send html diffs approach in the form of alpine and htmx. The other potential area for change on the horizon is web assembly getting host bindings support so it doesn't have to bridge through JS to affect the DOM and other browser APIs.

arnvald 5y ago
Thanks for a thorough explanation! I've heard about NextJS, NuxtJS etc. and I know they're built on top of React and Vue, but didn't really know what kind of value they provided, now that's clearer.
xdennis 5y ago
I'm not sure about that. 2014 is when Webpack was released and React was released the year prior. Maybe one or two years after that.

armchairhacker 5y ago

Honestly if anything, web frameworks are way ahead of the rest of the world. The real difficulty is that web UIs have to be very flexible and varied: you have different screen sizes, mobile vs desktop, and every website has a different UI vs native apps all looking similar. And yeah, there are over 100 different web frameworks most which have a particular use case, although you don't have to use the perfect tool for the job. Also, there are a few quirks left over from the old days of HTML/CSS/JavaScript. But making a basic website nowadays on modern tools is very straightforward. Clone a vite starter project, write out your DOM in React or Vue or Svelte or Solid.js or whatever, and launch a live-server with a browser inspector to fine-tune the design. There are some especially bad JS frameworks (looking at you Meteor), but that's the case for most platforms.

wruza 5y ago
Honestly if anything, web frameworks are way ahead of the rest of the world Made me chuckle. Web frameworks are thin-to-medium layers of dealing with bs that web graphics are by nature and design. Their entire purpose orbits around that. Runtimes that do not suffer from these birth traumas don’t even need all that complexity. E.g. with apple core ui libraries you can in hours design a new flex/grid/stack/align/etc geometry container (which takes decades in the web), can animate things, make them cheap-scrollable, sizeable, constrainable out of box. Do you really think that web reflows and size dispatch up and down a hierarchy is a complex issue which only a “top-notch” web tech can solve? Of course web traditionally was more game-like and does not have any guidelines and presentation standards beyond “reset”, allowing to focus on design better than the rest of the world (and due to widespread nature monopolized by a single platform), but calling frameworks which basically deal with its own shortcomings and ancient issues ahead of the world is pretty misleading. What exactly is ahead of the world in there? My bet is on reactivity, components, caching and lazy redraws, which “weren’t a thing” before web, because, you know, jquery and comctl32.dll were bad. making a basic website nowadays on modern tools is very straightforward … and launch a live-server with a browser inspector to fine-tune the design Ah yes, something we had at VB/Delphi 3 times but not quite as RAD. I mean, maybe launch a live server, drop a query and see live data in design-mode, or enumerate columns and make some of them editable out of box? Or fill a form with master-detail link? You can’t. Web praises primitive/workaround things which nobody even had a name for before, so trivial and obvious and default it was.