5 ms·

I think that's my pet peeve with modern frontend tooling, they feel like walled gardens of arbitrary knowledge that only applies to their ecosystem rather than

by ehnto 5y ago

I think that's my pet peeve with modern frontend tooling, they feel like walled gardens of arbitrary knowledge that only applies to their ecosystem rather than to some fundamental learning about software. When I learned about OOP I was able to understand OOP code in a broad range of applications, languages and frameworks, but learning how react works gives me no insight into anything but react, and it's even abstracted enough from JavaScript that you could learn React without ever properly knowing how to write JavaScript (which is something I've encountered in a handful of new devs).

pc86 5y ago
> they feel like walled gardens of arbitrary knowledge that only applies to their ecosystem rather than to some fundamental learning about software. This is sort of an expected side effect of recreating nearly-identical JS frameworks every couple months, no?
- mdtusz 5y ago
  I continue to see this idea posted in HN and Reddit programming threads and it comes across as ignorance more than anything. The reality is that nearly all new modern web applications will be written using react or vue, with a long tail choosing a more esoteric or experimental tool because it either fits the project requirements, or the team is willing to accept more risk in favour of some other benefit (often times just curiosity). Considering you have so few language options for frontend webapp development (excluding wasm and other such options), this really isn't a surprise to have a handful of options either. I can name more python server frameworks that are used in earnest than I can name frontend frameworks. Part of the difference for frontend frameworks is that there's so much variety possible. Nearly every server framework has the same general design and API - some kind of routing, route handler definitions, and some additional niceties like with, db connection handling, sessions etc. I can't conceive of any other design that would work better or even be sensible. While components have become the norm in front-end, there's still plenty of room for different architecture and actual API to use and define components, and manage state. That's where the fun of writing them comes in, and where there is still likely a better react or vue lurking in the shadows or yet to be created.
  - jaredgorski 5y ago
    I think both can be true. There are practical reasons to use React and Vue, but that practical approach is obfuscated by the zeitgeisty culture around tools that get unwisely applied to every use-case. Frontend architecture needs to be approached soberly and prudently. Not every site needs React and GraphQL.
    - mdtusz 5y ago
      I completely agree! What I intended with my comment was to point out that the idea of new frameworks being created every week is a bit of an exaggeration and that it being the reason frontend development is fragmented is just totally incorrect. React or Vue on their own with a sprinkling of helpful utility libraries will get most projects 99% of the way there though, and often times that _is_ simpler than trying to put together your own system for server side rendered pages and template composition. Of course, if you're making a blog, you don't need any of this, but for _web applications_, I don't think I'd reach for SSR anymore.
- nicoburns 5y ago
  React's been the dominant frontend framework for over 5 years at this point, and shows no sign of going away anytime soon.
- Zababa 5y ago
  AngularJS, Angular, React, Vue, Svelte. That's 5 in 11 years. I could add Knockout, Backbone, Meteor and Ember. That's 9 if you're stretching it. I don't know anything about the last 4, but the first 5 ones all offer different ways to do things. I would even argue that they are more different that the "canonical implementation of the backend MVC framework" and the "Sinatra copy" that you have in every language.
jaredgorski 5y ago
Absolutely. The trends and gimmicks have caused this “walled garden” effect. It’s made both “practical frontend engineers” and “practical frontend architecture” a rarity. If I could write this post again, I’d talk more about how most use-cases simply don’t need a “modern tech stack”. React is basically a glorified templating engine that attempts to enable reactive mechanisms on the client. Need “reactive”? Consider Svelte as well. Don’t need it? Consider moving the render to the build and use a lighter templating engine.
Weebs 5y ago
I think if we're talking about concepts at the level of OOP, we'd be comparing MVU and virtual DOMs rather than React. I learned to write UIs in F# through Elmish (used by Bolero), which was inspired by (unsurprisingly) Elm. React, also being inspired by Elm, was simple enough to transition to once I was comfortable in Bolero. It was basically MVU with components that have local state and lifetime function callbacks. I ended up tripping over TypeScript/JS more often than React At the same time, I do know what you mean about the walled garden ecosystems. It seems unfortunate that every framework I pick up, I'm learning a new set of components everyone uses for things like virtualization. On the backend it feels less common to be using a library that's only relevant to your stack, and when there's a killer library in another language, you don't need to move mountains to use it.
- iaml 5y ago
  > React, also being inspired by Elm This is news to me, are you sure about that? Wasn't react released earlier than elm?
  - Weebs 5y ago
    I believe you're right, I meant to say React's Hooks, but now I can't find a reference to that so maybe I misremembered. I wasn't interested in previous versions of React after going over the basics in the docs a few times, but after the introduction of hooks I found it more appealing.
    - insonifi 5y ago
      I think you actually meant Redux, which as an implementation of the Flux architecture was inspired by Elm, as per the author [1]. [1] https://egghead.io/podcasts/dan-abramov-co-author-of-redux https://egghead.io/podcasts/dan-abramov-co-author-of-redux
      - iaml 5y ago
        This is neat, didn't know about elm's influence on redux.
stickfigure 5y ago
I think you have it exactly backwards - the days of using string templates to assemble HTML pages was a weird and specialized era. React and modern JS tooling brings us back to traditional client/server GUI application development, just like we did in the 90s. And that's a good thing. GUI development has its own set of concepts and broad applications. React is somewhat novel but still fits squarely in here; the idea of a GUI component is pretty enduring. Distributed systems development has its own set of concepts and broad applications. With modern tooling, web interactions look just like traditional RPCs. I programmed "full-stack" through the GUI fat client era, the primitive web era, and now the modern web era. I'm much happier developing with the modern tools.
- rapind 5y ago
  > the days of using string templates to assemble HTML pages was a weird and specialized era. JSX?
  - stickfigure 5y ago
    ...does not generate strings.
    - rapind 5y ago
      and it isn't javascript, so it's essentially a template language. It's just being turned into javascript, which then goes into the vdom, which then gets diffed with the real DOM, which generates code to reconcile it with the real DOM. > the days of using string templates to assemble HTML pages was a weird and specialized era. I gotta say, I think React w/ JSX is far more of a weird and specialized era. The real difference you're talking about is having the server render each user's UI versus offloading that to the user's machine. Regardless of whether it's via strings, 1s and 0s, https, rpc, etc. Browser's have become a more powerful "general purpose" renderer, so it makes more sense that they'll continue to take on more of the UI work themselves. It's still not as good as a purpose built client though, as sluggish electron apps have demonstrated. And sometimes it might still make sense to render the UI on the server (and cache it) for either / both simplicity and performance. Occasionally you'll even do a bit of both with a client side app being rendered server side then hydrated... talk about a weird and specialized era.

by ehnto 5y ago

pc86 5y ago

> they feel like walled gardens of arbitrary knowledge that only applies to their ecosystem rather than to some fundamental learning about software. This is sort of an expected side effect of recreating nearly-identical JS frameworks every couple months, no?

mdtusz 5y ago
I continue to see this idea posted in HN and Reddit programming threads and it comes across as ignorance more than anything. The reality is that nearly all new modern web applications will be written using react or vue, with a long tail choosing a more esoteric or experimental tool because it either fits the project requirements, or the team is willing to accept more risk in favour of some other benefit (often times just curiosity). Considering you have so few language options for frontend webapp development (excluding wasm and other such options), this really isn't a surprise to have a handful of options either. I can name more python server frameworks that are used in earnest than I can name frontend frameworks. Part of the difference for frontend frameworks is that there's so much variety possible. Nearly every server framework has the same general design and API - some kind of routing, route handler definitions, and some additional niceties like with, db connection handling, sessions etc. I can't conceive of any other design that would work better or even be sensible. While components have become the norm in front-end, there's still plenty of room for different architecture and actual API to use and define components, and manage state. That's where the fun of writing them comes in, and where there is still likely a better react or vue lurking in the shadows or yet to be created.
- jaredgorski 5y ago
  I think both can be true. There are practical reasons to use React and Vue, but that practical approach is obfuscated by the zeitgeisty culture around tools that get unwisely applied to every use-case. Frontend architecture needs to be approached soberly and prudently. Not every site needs React and GraphQL.
  - mdtusz 5y ago
    I completely agree! What I intended with my comment was to point out that the idea of new frameworks being created every week is a bit of an exaggeration and that it being the reason frontend development is fragmented is just totally incorrect. React or Vue on their own with a sprinkling of helpful utility libraries will get most projects 99% of the way there though, and often times that _is_ simpler than trying to put together your own system for server side rendered pages and template composition. Of course, if you're making a blog, you don't need any of this, but for _web applications_, I don't think I'd reach for SSR anymore.
nicoburns 5y ago
React's been the dominant frontend framework for over 5 years at this point, and shows no sign of going away anytime soon.
Zababa 5y ago
AngularJS, Angular, React, Vue, Svelte. That's 5 in 11 years. I could add Knockout, Backbone, Meteor and Ember. That's 9 if you're stretching it. I don't know anything about the last 4, but the first 5 ones all offer different ways to do things. I would even argue that they are more different that the "canonical implementation of the backend MVC framework" and the "Sinatra copy" that you have in every language.

jaredgorski 5y ago

Absolutely. The trends and gimmicks have caused this “walled garden” effect. It’s made both “practical frontend engineers” and “practical frontend architecture” a rarity. If I could write this post again, I’d talk more about how most use-cases simply don’t need a “modern tech stack”. React is basically a glorified templating engine that attempts to enable reactive mechanisms on the client. Need “reactive”? Consider Svelte as well. Don’t need it? Consider moving the render to the build and use a lighter templating engine.

Weebs 5y ago

I think if we're talking about concepts at the level of OOP, we'd be comparing MVU and virtual DOMs rather than React. I learned to write UIs in F# through Elmish (used by Bolero), which was inspired by (unsurprisingly) Elm. React, also being inspired by Elm, was simple enough to transition to once I was comfortable in Bolero. It was basically MVU with components that have local state and lifetime function callbacks. I ended up tripping over TypeScript/JS more often than React At the same time, I do know what you mean about the walled garden ecosystems. It seems unfortunate that every framework I pick up, I'm learning a new set of components everyone uses for things like virtualization. On the backend it feels less common to be using a library that's only relevant to your stack, and when there's a killer library in another language, you don't need to move mountains to use it.

iaml 5y ago
> React, also being inspired by Elm This is news to me, are you sure about that? Wasn't react released earlier than elm?
- Weebs 5y ago
  I believe you're right, I meant to say React's Hooks, but now I can't find a reference to that so maybe I misremembered. I wasn't interested in previous versions of React after going over the basics in the docs a few times, but after the introduction of hooks I found it more appealing.
  - insonifi 5y ago
    I think you actually meant Redux, which as an implementation of the Flux architecture was inspired by Elm, as per the author [1]. [1] https://egghead.io/podcasts/dan-abramov-co-author-of-redux https://egghead.io/podcasts/dan-abramov-co-author-of-redux
    - iaml 5y ago
      This is neat, didn't know about elm's influence on redux.

stickfigure 5y ago

I think you have it exactly backwards - the days of using string templates to assemble HTML pages was a weird and specialized era. React and modern JS tooling brings us back to traditional client/server GUI application development, just like we did in the 90s. And that's a good thing. GUI development has its own set of concepts and broad applications. React is somewhat novel but still fits squarely in here; the idea of a GUI component is pretty enduring. Distributed systems development has its own set of concepts and broad applications. With modern tooling, web interactions look just like traditional RPCs. I programmed "full-stack" through the GUI fat client era, the primitive web era, and now the modern web era. I'm much happier developing with the modern tools.

rapind 5y ago
> the days of using string templates to assemble HTML pages was a weird and specialized era. JSX?
- stickfigure 5y ago
  ...does not generate strings.
  - rapind 5y ago
    and it isn't javascript, so it's essentially a template language. It's just being turned into javascript, which then goes into the vdom, which then gets diffed with the real DOM, which generates code to reconcile it with the real DOM. > the days of using string templates to assemble HTML pages was a weird and specialized era. I gotta say, I think React w/ JSX is far more of a weird and specialized era. The real difference you're talking about is having the server render each user's UI versus offloading that to the user's machine. Regardless of whether it's via strings, 1s and 0s, https, rpc, etc. Browser's have become a more powerful "general purpose" renderer, so it makes more sense that they'll continue to take on more of the UI work themselves. It's still not as good as a purpose built client though, as sluggish electron apps have demonstrated. And sometimes it might still make sense to render the UI on the server (and cache it) for either / both simplicity and performance. Occasionally you'll even do a bit of both with a client side app being rendered server side then hydrated... talk about a weird and specialized era.