4 ms·

>frankly, let's stop pretending the JS ecosystem is not problematic. Can anyone in good faith argue for a Node project React is a node project, so I can do so

by nawgz 6y ago

>frankly, let's stop pretending the JS ecosystem is not problematic. Can anyone in good faith argue for a Node project React is a node project, so I can do so trivially. React is a top tier library when it comes to key features like stability, documentation, backwards compatibility, and extensibility / usability. I can also say TypeScript is one of the most amazing projects of all time. Last but not least - express is super easy to use. I don't know what "dev-friendly" means, as a criteria though. Keep in mind, though, since it's JS, it's really easy to wrap and extend. To me, you have to justify how Flask is superior to Express; I think you just like Python more.

ralmidani 6y ago
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.
- 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

by nawgz 6y ago

ralmidani 6y ago

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