3 ms·

The first thing that jumped out at me was this: csv_data = [",".join(map(str, tbl.columns_dict))] csv_data += [",".join(map(str, row.values())) for row

The first thing that jumped out at me was this: csv_data = [",".join(map(str, tbl.columns_dict))] csv_data += [",".join(map(str, row.values())) for row in tbl()] Sigh. He's not "building the app". This code is wrong. It's not escaping the CSV properly, so embedded commas and similar control characters will result in gibberish output. I'm just so fed up with this JS+HTML SPA framework demos where everybody thinks that stringly-typed programming is the only way to do things, where instead of using a proper library that actually encodes/decodes file formats properly there's this kind of quick & dirty script snippet that is basically broken under all but ideal conditions. ("It worked, once, on my computer, with toy data. Job done!") I get it, this exercise is about comparing the essentials of different frameworks. But that comparison ought to include things that matter, such as correct handling of Accept-Language, safe escaping of data, sorting on date columns, virtualising lists too big to handle in one go, etc... That's what actually matters, that's what takes actual time when getting something to production. Not the folder structure or file naming conventions. The author mentions "How will coding assistants influence builders?" but ChatGPT can spot this kind of error, and more: https://chatgpt.com/share/793e6353-817f-4765-ab33-f3131906378c https://chatgpt.com/share/793e6353-817f-4765-ab33-f313190637...

spencerchubb 2y ago
You're focusing on the wrong aspect of the post. This post is comparing web frameworks, not showing how to build a correct csv handling app.
- jiggawatts 2y ago
  End-to-end correctness matters and should be a key deciding factor when choosing a web framework. Some frameworks make this easy, leading people to fall into the pit of success, other's make it very difficult, and it takes eternal vigilance starting the day after the Hello World demo. E.g.: Most of his demos use mixed languages (Python+JavaScript). This architecture leads to madness. There are endless subtle differences between how any two languages represent data, what they can and can't express, and whether they agree on things like data validation regex syntax or not. A proper comparison would cover issues such as internationalisation, async, data streaming[1], dependency injection, client and server validation that's kept in sync, authentication and authorization through the layers, etc... [1] Sure, he's got a toy use-case of CSV files, but CSV files can be huge! Most JS frameworks and Rest APIs will process such tabular data as giant blobs of JSON as a single response. They can't stream, they can't handle paging or windowing, or if they can, you have to "wire that up" on the client which gets complicated rapidly. Do that! That's the demo that interests me. Not an incorrect script that will run out of memory and crash the server if you process a file big enough to be useful. Too much work for a quick demo? Well, yes, that's my point! It shouldn't be.
  - okdang 2y ago
    [flagged]
  - spencerchubb 2y ago
    End-to-end correctness does not matter in a comparison. If every app implements the same functionality, then that is a valid comparison. Even if that functionality is incorrect.
    - hu3 2y ago
      It does matter because ultimately you'll have deploy correct code to production. A comparison of how easy or cumbersome it is to write production grade apps between frameworks is much more valuable. Otherwise we are back to comparing TODO demos.
    - YuukiRey 2y ago
      This seems like a pretty wild take. If five apps implement an authentication flow, 4 relying on the framework and one building it from scratch because the framework doesn't provide one, then surely that should be factored into any comparisons. If a framework comes with an opinionated templating system whereas another requires me to come up with a way to have nested templating (and whatever else I might require), then again, that should be a factor in my comparison.
jph00 2y ago
Creating a CSV correctly has nothing at all to do with choosing a framework. In Python there's a CSV module in the stdlib that you can use -- but talking about that in a discussion of frameworks tells you nothing about the frameworks, and would simply be a distraction.
- jiggawatts 2y ago
  It’s only a distraction if you can safely assume that code that runs on the server will never need a client-side component to match. Sure you can pull in random Python packages… but you can’t run them in the browser. You can with Blazor or Node on the server.

spencerchubb 2y ago

You're focusing on the wrong aspect of the post. This post is comparing web frameworks, not showing how to build a correct csv handling app.

jiggawatts 2y ago
End-to-end correctness matters and should be a key deciding factor when choosing a web framework. Some frameworks make this easy, leading people to fall into the pit of success, other's make it very difficult, and it takes eternal vigilance starting the day after the Hello World demo. E.g.: Most of his demos use mixed languages (Python+JavaScript). This architecture leads to madness. There are endless subtle differences between how any two languages represent data, what they can and can't express, and whether they agree on things like data validation regex syntax or not. A proper comparison would cover issues such as internationalisation, async, data streaming[1], dependency injection, client and server validation that's kept in sync, authentication and authorization through the layers, etc... [1] Sure, he's got a toy use-case of CSV files, but CSV files can be huge! Most JS frameworks and Rest APIs will process such tabular data as giant blobs of JSON as a single response. They can't stream, they can't handle paging or windowing, or if they can, you have to "wire that up" on the client which gets complicated rapidly. Do that! That's the demo that interests me. Not an incorrect script that will run out of memory and crash the server if you process a file big enough to be useful. Too much work for a quick demo? Well, yes, that's my point! It shouldn't be.
- okdang 2y ago
  [flagged]
- spencerchubb 2y ago
  End-to-end correctness does not matter in a comparison. If every app implements the same functionality, then that is a valid comparison. Even if that functionality is incorrect.
  - hu3 2y ago
    It does matter because ultimately you'll have deploy correct code to production. A comparison of how easy or cumbersome it is to write production grade apps between frameworks is much more valuable. Otherwise we are back to comparing TODO demos.
  - YuukiRey 2y ago
    This seems like a pretty wild take. If five apps implement an authentication flow, 4 relying on the framework and one building it from scratch because the framework doesn't provide one, then surely that should be factored into any comparisons. If a framework comes with an opinionated templating system whereas another requires me to come up with a way to have nested templating (and whatever else I might require), then again, that should be a factor in my comparison.

jph00 2y ago

Creating a CSV correctly has nothing at all to do with choosing a framework. In Python there's a CSV module in the stdlib that you can use -- but talking about that in a discussion of frameworks tells you nothing about the frameworks, and would simply be a distraction.

jiggawatts 2y ago
It’s only a distraction if you can safely assume that code that runs on the server will never need a client-side component to match. Sure you can pull in random Python packages… but you can’t run them in the browser. You can with Blazor or Node on the server.