4 ms·

React is stable? React.createElement -> Sub-classing the Component class -> "just use hooks everywhere" in the span of a few years? Sure, Django went from funct

React is stable? React.createElement -> Sub-classing the Component class -> "just use hooks everywhere" in the span of a few years? Sure, Django went from function-based to class-based views, but the change was far less abrupt, and you can still use functional views if you want to. As for TypeScript, I agree it's amazing, but it's neither a framework nor a library for building web applications. It's more of a superset/transpiler. It makes working with Node/React/Express better, but it doesn't replace them. With regard to Express, it's decent, but e.g. do we really need to torture newcomers by expecting them to know they'll need to also include/install and require body-parser? I mean, why would I be using a web framework, even a micro-one, if I'm expected to bring in a separate tool just for parsing requests? Regarding the suggestion that I like Python more, I would gladly choose TypeScript over Python (the typing tools there are still immature) if there was less churn in the JS ecosystem. Deno is promising. :)

nawgz 6y ago
>React is stable? Yes. Despite what you're trying to imply about them "updating" too often, my code from 2016 still works correctly against the newest versions of React. That's pretty much the definition of stability to me. > the change was far less abrupt, and you can still use functional views if you want to So you are hating on React because you don't know this, but this exact optional progression has always been how they have introduced new features into React. Again - old code works with new React versions. > do we really need to ... expect them to know True, this is a weakness, but the documentation is pretty explicit on this front. It's not like there isn't a big community around the library to address this. Anyhow, I respect your points here, and concede that writing server-side code in Node is probably not what you want to do; I reach for tools like Hasura in this case regardless. With low-code backend tooling and React, I can promise you I can make a better website than with just Python no matter how much Django template wizardry one can muster.
- ralmidani 6y ago
  Stability is not just about backward-compatibility; it also means promoting concepts/idioms which are consistent and long-lived. Django has been around for about 3 times as long as React, but has not undergone the same amount of churn that React has. If someone wrote React code in 2016 and left the scene for a couple of years, can they come back and build new React projects without significant re-training? Regarding Django templates, I know how they work, but actually prefer building an API with Django, and connecting to that with an SPA (preferably one built with Ember since, as you can probably tell, I prefer batteries-included frameworks). I'm really not as anti-JS as you inferred from my initial post (or as I unintentionally implied), but saying the ecosystem is not problematic makes it harder for it to get better.
  - d0100 6y ago
    > can they come back and build new React projects without significant re-training? The answer is yes
    - bryanrasmussen 6y ago
      with the proviso that anywhere you try to work at doing this will probably complain because you are not using the new way of doing things.
  - nawgz 6y ago
    > can they come back and build new React projects without significant re-training? Absolutely. For one, React introduced a few primary concepts: components, JSX, and the component lifecycle. Whether you wrote functional components, class components, or moved to the new hooks-based components, these lifecycles are behaving the same. The way you write the lifecycle hook might be slightly different in a hooks world but it still exists the same. JSX is almost entirely unchanged in my experience. Composability and other techniques to pass data or context thru to the children still work the same as ever. Accessing DOM nodes still works the same as previously but with a new method as well. In general, "the old way works but there's a new way too" sums up a lot of the core features. The library has updated and refined itself, but maintained back-compat with almost all old ways of using it, and conceptually stayed true.
- worik 6y ago
  "my code from 2016 still works correctly" That is no time at all in "enterprise level software", being software with investment counted in millions of dollars. What about your code from 1996? Will your React code word in thirty years?
  - nawgz 6y ago
    If you don't know why this was downvoted - React rose to popularity in 2014-2015, and so my code from 2016 working correctly implies that the library has remained compatible with code written almost at any point in its lifespan. Also, shouldn't "enterprise level software" prioritize new and improved ways of working for maintainability in 30 years anyhow? React & TypeScript is going to be a much more readable form of maintaining UIs than old-school template hodge-podge, direct HTML generation, jQuery, or whatever you want to point at. To that end, I answer "my React/TS code is more likely to work in 30 years than a legacy system being forced into the modern web world"
- julianmarq 6y ago
  > hating on React It would be great if developers stopped treating tools they like with this much sentiment. For starters, it would mean fewer flamewars. They're just tools, criticizing them is not "hating" and your liking them is no endorsement (for anyone other than you, anyway). > With low-code backend tooling and React, I can promise you I can make a better website than with just Python no matter how much Django template wizardry one can muster. How can you "promise" this? How can anyone "promise" this? I'm not even sure I understood what you meant by this. Even more so in this case as the tools you mentioned are geared to different types of applications. The only way I can parse this sentence is that you're claiming that react is indisputably better at [not sure what you meant to do since you said "website" and a website doesn't need a backend$, but you mentioned backend regardless] than any tool in [whatever other language/framework, clearly, even if you're using Python as example] and I'm gonna need a source on that one. It's a pretty strong claim, assuming I didn't misinterpret it. $ Technically, a website doesn't need a frontend either; it's debatable whether a website even needs javascript, but certainly not react, which is a library for creating web applications.
  - nawgz 6y ago
    > hating on React What do you call it when someone claims changes to the definition of "idiomatic" usage is the same as being not backwards compatible, incorrectly? I calmly corrected the incorrect statement. There is no flamewar here, but criticizing something incorrectly because of personal bias and lack of knowledge is more or less "hating" in a nutshell > How can you "promise" this? Because I am a pro web dev who has made a ton of apps and understands the difference in power between HTML templates and JS components? There are objective standards of user experience and for anything non-trivial a web application is clearly going to be more interactive and deliver the data and workflows in a more user-friendly way. Reporting, workflows, interactivity, visualizations, all are much better when they're done interactively with JavaScript than delivered as some static asset to the browser.
    - julianmarq 6y ago
      > What do you call it when someone claims changes to the definition of "idiomatic" usage is the same as being not backwards compatible, incorrectly? I calmly corrected the incorrect statement. A) I have a very different interpretation of the other person's comments• and I don't see anything factually incorrect in them, b) I would call what the other person said criticizing even if I vehemently disagreed, if just to keep the discussion productive, and c) there was no specific "correction" of anything in the comment I replied to; you only expressed that you think react is stable. > understands the difference in power between HTML templates and JS components Those HTML templates don't exist in a vacuum and are invoked by whatever language is being used in the backend. The only "advantage" javascript gives is that it saves you the blink of reload; beyond that, the logic of a web application doesn't change in the slightest regardless of where the html is being rendered. > There are objective standards of user experience and for anything non-trivial a web application is clearly going to be more interactive and deliver the data and workflows in a more user-friendly way The GCP console is a gigantic mostly angular based single page application. The AWS console is mostly a jsp based server side application. You know what they have in common beyond being dashboards for managing cloud platforms? They're both unwieldy giant hodgepodges of work by a multitude of different teams. There's no silver bullet. You have a preference for single page applications. That doesn't mean a user is going to like an unusable SPA more than a well architected server application more just because the SPA saves page reloads. > Reporting, workflows, interactivity, visualizations, all are much better when they're done interactively with JavaScript than delivered as some static asset to the browser. I originally asked for a source of your claims, and I would really like to see your data for this. Let me turn your original claim on its head: With proper backend tooling (be it Rails, or Django, or whatever else) and a low-javascript, progressive enhancement library like htmx, I can "promise" you I can make a better web application than with just javascript, no matter how much JSX hacking one can muster. But I don't actually believe that, because it's better to use the right tool for the job. Sometimes an SPA framework is the right tool, and in that case I'll go for vue or svelte. After all, they're vastly superior to react ( ;) ). • For starters, most of them were about the javascript ecosystem in general; for that matter, you've been focusing on react more than anyone else in this exchange.
- atom_arranger 6y ago
  The other thing is that anyone who isn’t oblivious has seen the writing on the wall (React docs and changelogs) saying that class components are not the happy path of React development. This has been clear since late 2015. The only people I could see not noticing or ignoring this are people new to React or people who are emotionally attached to classes.
sli 6y ago
I really wish I saw what everyone else sees in TypeScript because that language has not sold itself to me at all, even using it professionally for years now. Even using it's primary feature can be a pain because nobody documents their types as far as I've found. It's surprisingly common for me to write code that compiles but crashes at runtime. Other, better JS-targeting languages manage to allow me to retain type-level features at runtime while also outputting leaner, faster, and safer code. The only value prop I really see is the momentum, but it feels like a huge push for the right reasons and in the worst possible direction. It's not that TypeScript hasn't helped at all, it just doesn't feel like it's this revolutionary thing that people treat it as. And I'm not even going to touch how visually noisy and distracting I find the C#-style type syntax to be.
- valand 6y ago
  Good at compile-time, breaks at runtime. It is because TypeScript doesn't want to diverge far from JavaScript. TypeScript compiles to JavaScript and if you give the wrong input you'll end up with runtime errors. Usually this happens with casting. Casting an `any` variable as `string` doesn't do anything other than letting the compiler knows that it must be string. It doesn't transform the variable and throw error when it is not string. This is a bit like casting struct pointer in C. This usually happens at IO: `fetch`, `localstorage`, `fs.readFileSync`, etc. It can't be solved purely with TypeScript. I used `io-ts` to mitigate this problem. This is a good paradigm to adopt in TypeScript projects https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-validate/ https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-va.... Other than data type, brutally tweaking your tsconfig (and webpack or rollup, if you use them) can also cause errors in module resolution, which is not a nice thing. TypeScript is almost revolutionary. The thing I wish to exist is a superset of TypeScript that allows Rust-like macro. It is super handful, super beautiful.
- nawgz 6y ago
  > I really wish I saw what everyone else sees in TypeScript > It's surprisingly common for me to wrrite code that compiles but crashes at runtime Well, is it also common for you to allow `any` in your code? TypeScript is strongest when it can type-check your entire code. If your API endpoints return data that doesn't match your type (or at any other external data load point), TypeScript clearly can't help with that. I'm actually quite sure that if you have this kind of behavior in TypeScript, your other JS-targeting languages would fail too; you have just mis-typed something. > Other, better Yes, you're not biased > JS-targeting languages manage to allow me to retain type-level features at runtime What does this mean? They compile to put a magic key `_type` on an object? > while also outputting leaner, faster, and safer code I highly dispute your claims. You're building JS still, it's not going to be magically better - this just means you write bad TS. Show me some numbers or some code to make this claim. > it feels like a huge push for the right reasons and in the worst possible direction Given that you started your complaint with "no one documents their types", I am not so inclined to listen to your opinion. Types are the documentation. Interface names, key names, types, full autocorrect interacting with any objects, generic type support, reasonably smart type solver / caster, great error messages; these are all things TypeScript offers for learning a thin extension of JS. > I'm not even going to touch how visually noisy and distracting I find the C#-style type syntax to be Why not? I would love to hear more ridiculous complaints which only make sense thru your personal lens and have no justification or empirical evidence behind them

nawgz 6y ago

>React is stable? Yes. Despite what you're trying to imply about them "updating" too often, my code from 2016 still works correctly against the newest versions of React. That's pretty much the definition of stability to me. > the change was far less abrupt, and you can still use functional views if you want to So you are hating on React because you don't know this, but this exact optional progression has always been how they have introduced new features into React. Again - old code works with new React versions. > do we really need to ... expect them to know True, this is a weakness, but the documentation is pretty explicit on this front. It's not like there isn't a big community around the library to address this. Anyhow, I respect your points here, and concede that writing server-side code in Node is probably not what you want to do; I reach for tools like Hasura in this case regardless. With low-code backend tooling and React, I can promise you I can make a better website than with just Python no matter how much Django template wizardry one can muster.

ralmidani 6y ago
Stability is not just about backward-compatibility; it also means promoting concepts/idioms which are consistent and long-lived. Django has been around for about 3 times as long as React, but has not undergone the same amount of churn that React has. If someone wrote React code in 2016 and left the scene for a couple of years, can they come back and build new React projects without significant re-training? Regarding Django templates, I know how they work, but actually prefer building an API with Django, and connecting to that with an SPA (preferably one built with Ember since, as you can probably tell, I prefer batteries-included frameworks). I'm really not as anti-JS as you inferred from my initial post (or as I unintentionally implied), but saying the ecosystem is not problematic makes it harder for it to get better.
- d0100 6y ago
  > can they come back and build new React projects without significant re-training? The answer is yes
  - bryanrasmussen 6y ago
    with the proviso that anywhere you try to work at doing this will probably complain because you are not using the new way of doing things.
- nawgz 6y ago
  > can they come back and build new React projects without significant re-training? Absolutely. For one, React introduced a few primary concepts: components, JSX, and the component lifecycle. Whether you wrote functional components, class components, or moved to the new hooks-based components, these lifecycles are behaving the same. The way you write the lifecycle hook might be slightly different in a hooks world but it still exists the same. JSX is almost entirely unchanged in my experience. Composability and other techniques to pass data or context thru to the children still work the same as ever. Accessing DOM nodes still works the same as previously but with a new method as well. In general, "the old way works but there's a new way too" sums up a lot of the core features. The library has updated and refined itself, but maintained back-compat with almost all old ways of using it, and conceptually stayed true.
worik 6y ago
"my code from 2016 still works correctly" That is no time at all in "enterprise level software", being software with investment counted in millions of dollars. What about your code from 1996? Will your React code word in thirty years?
- nawgz 6y ago
  If you don't know why this was downvoted - React rose to popularity in 2014-2015, and so my code from 2016 working correctly implies that the library has remained compatible with code written almost at any point in its lifespan. Also, shouldn't "enterprise level software" prioritize new and improved ways of working for maintainability in 30 years anyhow? React & TypeScript is going to be a much more readable form of maintaining UIs than old-school template hodge-podge, direct HTML generation, jQuery, or whatever you want to point at. To that end, I answer "my React/TS code is more likely to work in 30 years than a legacy system being forced into the modern web world"
julianmarq 6y ago
> hating on React It would be great if developers stopped treating tools they like with this much sentiment. For starters, it would mean fewer flamewars. They're just tools, criticizing them is not "hating" and your liking them is no endorsement (for anyone other than you, anyway). > With low-code backend tooling and React, I can promise you I can make a better website than with just Python no matter how much Django template wizardry one can muster. How can you "promise" this? How can anyone "promise" this? I'm not even sure I understood what you meant by this. Even more so in this case as the tools you mentioned are geared to different types of applications. The only way I can parse this sentence is that you're claiming that react is indisputably better at [not sure what you meant to do since you said "website" and a website doesn't need a backend$, but you mentioned backend regardless] than any tool in [whatever other language/framework, clearly, even if you're using Python as example] and I'm gonna need a source on that one. It's a pretty strong claim, assuming I didn't misinterpret it. $ Technically, a website doesn't need a frontend either; it's debatable whether a website even needs javascript, but certainly not react, which is a library for creating web applications.
- nawgz 6y ago
  > hating on React What do you call it when someone claims changes to the definition of "idiomatic" usage is the same as being not backwards compatible, incorrectly? I calmly corrected the incorrect statement. There is no flamewar here, but criticizing something incorrectly because of personal bias and lack of knowledge is more or less "hating" in a nutshell > How can you "promise" this? Because I am a pro web dev who has made a ton of apps and understands the difference in power between HTML templates and JS components? There are objective standards of user experience and for anything non-trivial a web application is clearly going to be more interactive and deliver the data and workflows in a more user-friendly way. Reporting, workflows, interactivity, visualizations, all are much better when they're done interactively with JavaScript than delivered as some static asset to the browser.
  - julianmarq 6y ago
    > What do you call it when someone claims changes to the definition of "idiomatic" usage is the same as being not backwards compatible, incorrectly? I calmly corrected the incorrect statement. A) I have a very different interpretation of the other person's comments• and I don't see anything factually incorrect in them, b) I would call what the other person said criticizing even if I vehemently disagreed, if just to keep the discussion productive, and c) there was no specific "correction" of anything in the comment I replied to; you only expressed that you think react is stable. > understands the difference in power between HTML templates and JS components Those HTML templates don't exist in a vacuum and are invoked by whatever language is being used in the backend. The only "advantage" javascript gives is that it saves you the blink of reload; beyond that, the logic of a web application doesn't change in the slightest regardless of where the html is being rendered. > There are objective standards of user experience and for anything non-trivial a web application is clearly going to be more interactive and deliver the data and workflows in a more user-friendly way The GCP console is a gigantic mostly angular based single page application. The AWS console is mostly a jsp based server side application. You know what they have in common beyond being dashboards for managing cloud platforms? They're both unwieldy giant hodgepodges of work by a multitude of different teams. There's no silver bullet. You have a preference for single page applications. That doesn't mean a user is going to like an unusable SPA more than a well architected server application more just because the SPA saves page reloads. > Reporting, workflows, interactivity, visualizations, all are much better when they're done interactively with JavaScript than delivered as some static asset to the browser. I originally asked for a source of your claims, and I would really like to see your data for this. Let me turn your original claim on its head: With proper backend tooling (be it Rails, or Django, or whatever else) and a low-javascript, progressive enhancement library like htmx, I can "promise" you I can make a better web application than with just javascript, no matter how much JSX hacking one can muster. But I don't actually believe that, because it's better to use the right tool for the job. Sometimes an SPA framework is the right tool, and in that case I'll go for vue or svelte. After all, they're vastly superior to react ( ;) ). • For starters, most of them were about the javascript ecosystem in general; for that matter, you've been focusing on react more than anyone else in this exchange.
atom_arranger 6y ago
The other thing is that anyone who isn’t oblivious has seen the writing on the wall (React docs and changelogs) saying that class components are not the happy path of React development. This has been clear since late 2015. The only people I could see not noticing or ignoring this are people new to React or people who are emotionally attached to classes.

sli 6y ago

I really wish I saw what everyone else sees in TypeScript because that language has not sold itself to me at all, even using it professionally for years now. Even using it's primary feature can be a pain because nobody documents their types as far as I've found. It's surprisingly common for me to write code that compiles but crashes at runtime. Other, better JS-targeting languages manage to allow me to retain type-level features at runtime while also outputting leaner, faster, and safer code. The only value prop I really see is the momentum, but it feels like a huge push for the right reasons and in the worst possible direction. It's not that TypeScript hasn't helped at all, it just doesn't feel like it's this revolutionary thing that people treat it as. And I'm not even going to touch how visually noisy and distracting I find the C#-style type syntax to be.

valand 6y ago
Good at compile-time, breaks at runtime. It is because TypeScript doesn't want to diverge far from JavaScript. TypeScript compiles to JavaScript and if you give the wrong input you'll end up with runtime errors. Usually this happens with casting. Casting an `any` variable as `string` doesn't do anything other than letting the compiler knows that it must be string. It doesn't transform the variable and throw error when it is not string. This is a bit like casting struct pointer in C. This usually happens at IO: `fetch`, `localstorage`, `fs.readFileSync`, etc. It can't be solved purely with TypeScript. I used `io-ts` to mitigate this problem. This is a good paradigm to adopt in TypeScript projects https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-validate/ https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-va.... Other than data type, brutally tweaking your tsconfig (and webpack or rollup, if you use them) can also cause errors in module resolution, which is not a nice thing. TypeScript is almost revolutionary. The thing I wish to exist is a superset of TypeScript that allows Rust-like macro. It is super handful, super beautiful.
nawgz 6y ago
> I really wish I saw what everyone else sees in TypeScript > It's surprisingly common for me to wrrite code that compiles but crashes at runtime Well, is it also common for you to allow `any` in your code? TypeScript is strongest when it can type-check your entire code. If your API endpoints return data that doesn't match your type (or at any other external data load point), TypeScript clearly can't help with that. I'm actually quite sure that if you have this kind of behavior in TypeScript, your other JS-targeting languages would fail too; you have just mis-typed something. > Other, better Yes, you're not biased > JS-targeting languages manage to allow me to retain type-level features at runtime What does this mean? They compile to put a magic key `_type` on an object? > while also outputting leaner, faster, and safer code I highly dispute your claims. You're building JS still, it's not going to be magically better - this just means you write bad TS. Show me some numbers or some code to make this claim. > it feels like a huge push for the right reasons and in the worst possible direction Given that you started your complaint with "no one documents their types", I am not so inclined to listen to your opinion. Types are the documentation. Interface names, key names, types, full autocorrect interacting with any objects, generic type support, reasonably smart type solver / caster, great error messages; these are all things TypeScript offers for learning a thin extension of JS. > I'm not even going to touch how visually noisy and distracting I find the C#-style type syntax to be Why not? I would love to hear more ridiculous complaints which only make sense thru your personal lens and have no justification or empirical evidence behind them