5 ms·

The main contention of the article is that this "simplicity" is illusory. You end up writing just as much code, but now you've added a complex dependency you do

by takno 10y ago

The main contention of the article is that this "simplicity" is illusory. You end up writing just as much code, but now you've added a complex dependency you don't really understand but have to make your customers download, and ultimately have to test against

gjolund 10y ago
That seems incredibly anecdotal. Perhaps if you don't understand the framework you are using. Ember (for example), takes care of huge swathes of complexity for you. I can't imagine trying to build a: * client side router * data transportation/cache layer * view layer * model layer * build pipeline ... and more, in less code that just `npm install -g ember-cli` `ember new my-app` And then having a common app structure with thousands of other people that can provide help and insight. You people really are kidding yourselves. I feel bad for whoever is paying your salaries.
- takno 10y ago
  I'm paying my salary. In my last performance review I rated myself outstanding and gave myself a substantial bonus. Frankly my employer is a little bit irritated by your arrogant comments about his hiring policies You list a lot of things that a framework gives you, but they vary between the small (routers are easy if you can ignore #) and the things which you probably don't need but have been convinced you want by your framework
  - gjolund 10y ago
    Hilarious. You are the only person working on the project and you are patting yourself on the back for writing "maintainable" code. Bring 50 more people into the project and then lets talk.
    - shitgoose 10y ago
      why 50? make it 500! Better yet, make it 5,000 of skilled offshore developers 12 hours away, capable of cranking up few megabytes of code per week each, full test coverage, mocks and injections. Now we are talking! That is maintainable!
      - gjolund 10y ago
        Exactly. It is like trying to explain a car assembly line to a guy with a junker in his garage.
        shitgoose 10y ago
        was that sarcasm level 2? Or you are serious? Either way, I am impressed!
- Svenskunganka 10y ago
  > And then having a common app structure with thousands of other people that can provide help and insight. You don't think that there are thousands of people who can provide help and insight into the standard Web & DOM API's? I mean, do you in all seriousness think that there are more people that can help you with React than it is that can help you with the Web & DOM API? Not to mention the standard browser libraries have decades worth of documentation and information about them, freely available. > * client side router * data transportation/cache layer * view layer * model layer * build pipeline Let's narrow that down a bit: client-side router - There's examples online of a router that's 20 lines[1] data transportation/cache layer - Umm, what? The browser already takes care of data transportation (also known as the HTTP protocol, WebSocket protocol or WebRTC - whichever floats your boat). Surprisingly, it also takes care of caching as well. view layer - if you absolutely need one, here[2] - 2KB and has everything you need. model layer - `class Model { ... }` and `let model = new Model('path/to/component')`. Simple as that. build pipeline - don't really need to "build" thanks to HTTP/2. Otherwise if you want to transpile anything you could always just setup a single-line `npm run build` script. > You people really are kidding yourselves. I feel bad for whoever is paying your salaries. Why can't you try to have a friendly discussion instead of attacking on a personal level as you've done countless times throughout the comments. Nobody's pointing a gun at you. [1] - http://joakim.beng.se/blog/posts/a-javascript-router-in-20-lines.html http://joakim.beng.se/blog/posts/a-javascript-router-in-20-l... [2] - https://github.com/pakastin/frzr https://github.com/pakastin/frzr
  - khattam 10y ago
    >There's examples online of a router that's 20 lines Yes, 20 lines which you have to be responsible for and maintain... and changes over time add up to make it 200. >The browser already takes care of data transportation ... HTTP protocol, WebSocket protocol or WebRTC Yep, with boilerplate code that you have to write and again, grows as your use cases grow. >if you absolutely need one, here (frzr) Oh, some view layer some guy came up with 22 days ago... or something that has been working for a decade for facebook. I wonder which one I want to go with.
    - sgift 10y ago
- BinaryIdiot 10y ago
  > I can't imagine trying to build a: * client side router * data transportation/cache layer * view layer * model layer * build pipeline Why can't you? Routers are easy; you likely don't need more than a few lines of code to accomplish most of what you need. Caching and data transportation is also easy and simple (there are a million cache libraries if you don't want to write a small one). Views and models have been done since the 90s and are relatively easy as well (in fact I wrote one in just a few minutes the other day to drop some dependencies from a personal project). Though models are not always the best way but I'm digressing. Build pipelines usually add more complexity than needed in my experience. I almost always, eventually, nix whatever complicated build pipeline I start out with and go with something dead simple. Most of this stuff has been done for over 15 years on the web. It's at the point where it should be mostly boilerplate / routine if you're not using a framework.
  - khattam 10y ago
    > It's at the point where it should be mostly boilerplate / routine Yes, that is EXACTLY what many of these frameworks are.
  - deathanatos 10y ago
    > Routers are easy; you likely don't need more than a few lines of code to accomplish most of what you need. Router as in delegating a URL to a handler for that URL? I wrote one once … and it is deceptive and not easy; most of the server side ones that I've encountered (e.g., Django, Flask, nginx) do a poor job.¹ The naive implementation of a mapping of regexes to handlers is dead simple to implement, but not very ergonomic to really use. Something that understands that paths are hierarchies works a lot better. Then it's also nice to have something that can stub out a component to a variable (and preferably type check that), e.g., "/customers/:customer_id", and pass you "customer_id" after validating it to be an integer, a UUID, or whatever. Then you need the capability to delegate an entire subtrees to a subrouter, and maybe if we could just get some handling of delegation based on the method in here, but HEAD needs to be automatic…, and canonicalization of URLs would be nice too. ¹I feel like this is one of those things that until you've seen something better, you're still wanting the faster horse.
- bobwaycott 10y ago
  What? Seriously? If you can't imagine trying to build these things, why on earth should you be trusted to use these things built by others? All of your comments in this thread are so unnecessarily abrasive. And you just continue to give off an unfounded and indefensible air of smug superiority, when what you're really falling back on is ... the ability to run a command that puts you in a padded room so you don't hurt yourself?
  - thatswrong0 10y ago
    > I can't imagine trying to build a ... and more, in less code that just...
    - bobwaycott 10y ago
      The other half of that "less code that[sic] just" is no code at all, and a reliance on a pkg manager command. It's a useless comparison, and wasn't at all lost on me.

by takno 10y ago

gjolund 10y ago

That seems incredibly anecdotal. Perhaps if you don't understand the framework you are using. Ember (for example), takes care of huge swathes of complexity for you. I can't imagine trying to build a: * client side router * data transportation/cache layer * view layer * model layer * build pipeline ... and more, in less code that just `npm install -g ember-cli` `ember new my-app` And then having a common app structure with thousands of other people that can provide help and insight. You people really are kidding yourselves. I feel bad for whoever is paying your salaries.

takno 10y ago
I'm paying my salary. In my last performance review I rated myself outstanding and gave myself a substantial bonus. Frankly my employer is a little bit irritated by your arrogant comments about his hiring policies You list a lot of things that a framework gives you, but they vary between the small (routers are easy if you can ignore #) and the things which you probably don't need but have been convinced you want by your framework
- gjolund 10y ago
  Hilarious. You are the only person working on the project and you are patting yourself on the back for writing "maintainable" code. Bring 50 more people into the project and then lets talk.
  - shitgoose 10y ago
    why 50? make it 500! Better yet, make it 5,000 of skilled offshore developers 12 hours away, capable of cranking up few megabytes of code per week each, full test coverage, mocks and injections. Now we are talking! That is maintainable!
    - gjolund 10y ago
      Exactly. It is like trying to explain a car assembly line to a guy with a junker in his garage.
      - shitgoose 10y ago
        was that sarcasm level 2? Or you are serious? Either way, I am impressed!
Svenskunganka 10y ago
> And then having a common app structure with thousands of other people that can provide help and insight. You don't think that there are thousands of people who can provide help and insight into the standard Web & DOM API's? I mean, do you in all seriousness think that there are more people that can help you with React than it is that can help you with the Web & DOM API? Not to mention the standard browser libraries have decades worth of documentation and information about them, freely available. > * client side router * data transportation/cache layer * view layer * model layer * build pipeline Let's narrow that down a bit: client-side router - There's examples online of a router that's 20 lines[1] data transportation/cache layer - Umm, what? The browser already takes care of data transportation (also known as the HTTP protocol, WebSocket protocol or WebRTC - whichever floats your boat). Surprisingly, it also takes care of caching as well. view layer - if you absolutely need one, here[2] - 2KB and has everything you need. model layer - `class Model { ... }` and `let model = new Model('path/to/component')`. Simple as that. build pipeline - don't really need to "build" thanks to HTTP/2. Otherwise if you want to transpile anything you could always just setup a single-line `npm run build` script. > You people really are kidding yourselves. I feel bad for whoever is paying your salaries. Why can't you try to have a friendly discussion instead of attacking on a personal level as you've done countless times throughout the comments. Nobody's pointing a gun at you. [1] - http://joakim.beng.se/blog/posts/a-javascript-router-in-20-lines.html http://joakim.beng.se/blog/posts/a-javascript-router-in-20-l... [2] - https://github.com/pakastin/frzr https://github.com/pakastin/frzr
- khattam 10y ago
  >There's examples online of a router that's 20 lines Yes, 20 lines which you have to be responsible for and maintain... and changes over time add up to make it 200. >The browser already takes care of data transportation ... HTTP protocol, WebSocket protocol or WebRTC Yep, with boilerplate code that you have to write and again, grows as your use cases grow. >if you absolutely need one, here (frzr) Oh, some view layer some guy came up with 22 days ago... or something that has been working for a decade for facebook. I wonder which one I want to go with.
  - sgift 10y ago
BinaryIdiot 10y ago
> I can't imagine trying to build a: * client side router * data transportation/cache layer * view layer * model layer * build pipeline Why can't you? Routers are easy; you likely don't need more than a few lines of code to accomplish most of what you need. Caching and data transportation is also easy and simple (there are a million cache libraries if you don't want to write a small one). Views and models have been done since the 90s and are relatively easy as well (in fact I wrote one in just a few minutes the other day to drop some dependencies from a personal project). Though models are not always the best way but I'm digressing. Build pipelines usually add more complexity than needed in my experience. I almost always, eventually, nix whatever complicated build pipeline I start out with and go with something dead simple. Most of this stuff has been done for over 15 years on the web. It's at the point where it should be mostly boilerplate / routine if you're not using a framework.
- khattam 10y ago
  > It's at the point where it should be mostly boilerplate / routine Yes, that is EXACTLY what many of these frameworks are.
- deathanatos 10y ago
  > Routers are easy; you likely don't need more than a few lines of code to accomplish most of what you need. Router as in delegating a URL to a handler for that URL? I wrote one once … and it is deceptive and not easy; most of the server side ones that I've encountered (e.g., Django, Flask, nginx) do a poor job.¹ The naive implementation of a mapping of regexes to handlers is dead simple to implement, but not very ergonomic to really use. Something that understands that paths are hierarchies works a lot better. Then it's also nice to have something that can stub out a component to a variable (and preferably type check that), e.g., "/customers/:customer_id", and pass you "customer_id" after validating it to be an integer, a UUID, or whatever. Then you need the capability to delegate an entire subtrees to a subrouter, and maybe if we could just get some handling of delegation based on the method in here, but HEAD needs to be automatic…, and canonicalization of URLs would be nice too. ¹I feel like this is one of those things that until you've seen something better, you're still wanting the faster horse.
bobwaycott 10y ago
What? Seriously? If you can't imagine trying to build these things, why on earth should you be trusted to use these things built by others? All of your comments in this thread are so unnecessarily abrasive. And you just continue to give off an unfounded and indefensible air of smug superiority, when what you're really falling back on is ... the ability to run a command that puts you in a padded room so you don't hurt yourself?
- thatswrong0 10y ago
  > I can't imagine trying to build a ... and more, in less code that just...
  - bobwaycott 10y ago
    The other half of that "less code that[sic] just" is no code at all, and a reliance on a pkg manager command. It's a useless comparison, and wasn't at all lost on me.