5 ms·

I find that when you start rolling your own framework, you just end up making crappier versions of what's in Angular, Ember, etc. What's worse, a custom framew

by cdmckay 10y ago

I find that when you start rolling your own framework, you just end up making crappier versions of what's in Angular, Ember, etc. What's worse, a custom framework won't be known by any new developers, so you'll have to spend more resources onboarding them than, say, if you just had to show them how you're using Angular in your company (i.e. they'll already understand things like directives, components, etc.) Finally, you lose the advantages of having an ecosystem of plugins, support, etc. It just doesn't make any sense to me to roll your own. Any initial speed you gain you end up paying for later on. To me, using something like Angular means I can harness the experience and expertise of dozens of superstar coders at Google whose only job is to think about the best way to write SPA frameworks. Why would I not take advantage of that?

jasonkester 10y ago
I find that when you start rolling your own framework, you just end up making crappier versions of what's in Angular, Ember, etc. And that's a good thing. The distinction is that you're making a crappy general purpose framework, but you're making a really good problem specific framework that exactly fits the thing you're building. The reason those frameworks you list are so "bloated" is that their developers have spent so much time polishing them up and general-purpose-izing them so that Everybody can use them for Everything. Your thing is only for You to do Your Thing, so it can be much lighter and to the point.
- Cthulhu_ 10y ago
  > but you're making a really good problem specific framework that exactly fits the thing you're building. Except when you don't. A lot of people, when they realize they're building a framework, start over-engineering (YAGNI). Another issue is that they, for example, build a template renderer but miss a lot of edge cases, opening their application up for script injection and other such nasty things. Ten or so years ago, PHP had the same disease - people thinking they're hot shit, building their own frameworks, writing wrong tutorials on how to e.g. connect to a database because they thought they knew how that worked. This resulted in a huge amount of SQL injection issues, millions if not billions of hacked accounts, and billions in damages. TL;DR don't write your own framework, please.
  - geebee 10y ago
    Id agree, but add my own plea: please dont write an spa if you dont need one. Yes I left that a bit ambiguous, but it is harder to manage and work witha rails and ember app than a reg'lear ol rails app. Thats cool if are genuinely getting something out of it. "Ember experiece" on your resume doesnt count. Except that it does, bummed, but i do understand.
  - deleted 10y ago
    [deleted]
  - dreistdreist 10y ago
    PHP did not have a useful package manager back then. It has now. Custom solution built on top of stable components > general purpose framework
- mklim 10y ago
  >The distinction is that you're making a crappy general purpose framework, but you're making a really good problem specific framework that exactly fits the thing you're building. Strongly disagree. Your hand-rolled framework is undocumented besides whatever comments you've put in your code, full of bugs besides whatever you've personally stumbled into, and lacks anything except the features you've needed thus far. It's a means-to-an-end to get the actual features you need done done, instead of built for its own sake and tested and polished for its own sake. The second your application grows in an unexpected way, you need to augment the entire framework to suit. If there's a bug, you can't search stackoverflow or the github page and just read the answer that 500 other people have found before you, and neither can anyone who has to take over the code after you and try to maintain it--you are the sole author, your internal comments and notes and email chains are all the documentation for the framework that exists in the entire world, there's no hope for the maintainers besides slogging through the source and discovering the solution from scratch. There is no cheerful dev community contributing PRs for the buggy edge cases that break your code on obscure browsers. There's no helpful blog posts out there on how to tweak it for performance optimization. It's all just you trying to maintain what really should be its own full time project while you're trying to build a real product on top of it at the same time. IME, hand-rolling your own framework as you're building a product gets you the bare minimum (read: extremely poor) mess of code that could possibly address your core use case, not something good for your specific problem. Using multiple libraries instead of monolithic frameworks I think is generally a good idea, depending on context--but completely hand-rolling your own framework from scratch while you're actively developing a product, no, I've never once seen this work well.
  - treehau5 10y ago
    > The second your application grows in an unexpected way, you need to augment the entire framework to suit The second you need to do something your framework doesn't, the same rule applies. Frameworks are really good for covering most things, but almost everyone runs into that last 5-10% or so that it doesn't do. That ends up being the most difficult, in my experience.
    - jakub_g 10y ago
- thewhitetulip 10y ago
  I understand that rather than rolling out your own web framework we can just use existing frameworks. What are your thoughts about using libraries and not frameworks, like what what is popular with the Go language?
- stickfigure 10y ago
  you're making a really good problem specific framework You really aren't. Well -- I don't know you personally, but speaking statistically, your homegrown one-off framework only makes sense to you and will require a major rewrite to accommodate that feature you want to add next week. And you're going to spend all your time until then debugging a glitchy state transition.
- matt4077 10y ago
  Well, every app is a snowflake, but there's now a pretty good snowflake framework. Meaning: programming is all about abstractions, and if you hit the right level, all applications pretty much converge. Considering the manpower invested into today's frameworks and tooling, any single individual or small team doesn't stand a chance. Though the learning curve is much too steep at the moment. It's improving, mostly because 10-level deep callbacks are being replaced with promises/await/async, but especially the tooling is still a daunting challenge for many. There are now a few promising methods to get something running fast (create-react-app), but that seems to lead to opaque systems that usually work, but are prone to end up completely broken and incomprehensible when you're trying to customize them – because, for example, they do not validate their config files, use inconsistent naming, or deeply nested json where any deviation from the expected structure leads to silent failure.
- matwood 10y ago
  > The distinction is that you're making a crappy general purpose framework, but you're making a really good problem specific framework that exactly fits the thing you're building. But are you really? I'm not against rolling my own framework, but there needs to be very specifics reasons. The are so many reasons why using a popular framework is a good thing, that there have to be some very good reasons to roll my own. > Your thing is only for You to do Your Thing, so it can be much lighter and to the point. Unfortunately every time I have seen this reasoning used, it falls apart after starting. Rarely is software static, and instead it continues to grow. The custom framework may be lighter and to the point when you start and 6 months from now it is a bad copy of a common framework you could have just used off the shelf.
- mwcampbell 10y ago
  > Your thing is only for You to do Your Thing, so it can be much lighter and to the point. And also doesn't handle things that didn't occur to you, like accessibility. Some of that bloat is actually useful, even necessary, to someone.
- deleted 10y ago
  [deleted]
ofcapl_ 10y ago
I think in the best case scenario there should be a framework that doesn't need dedicated plugins - just using e.g. jQuery ones (because it has gazillions of them (plugins) already) - that would be wonderful
snarfy 10y ago
> To me, using something like Angular means I can harness the experience and expertise of dozens of superstar coders at Google You give them too much credit, and yourself not enough.
- mwcampbell 10y ago
  > You give them too much credit, and yourself not enough. On the contrary, the framework developers at Google, Facebook, etc. spend time on things that most web application developers do not. For example, accessibility for people with disabilities. If more web application developers would use these frameworks and follow the associated best practices, rather than all wanting to do things their own way, then maybe someday web applications will be accessible by default.
nojvek 10y ago
Disagree. Angular is a giant piece of bloated cheap that tries to do everything. I'm so glad someone wrote preact By using tools that do one thing and one thing very well it's easy to couple them together in interesting ways.

by cdmckay 10y ago

jasonkester 10y ago

I find that when you start rolling your own framework, you just end up making crappier versions of what's in Angular, Ember, etc. And that's a good thing. The distinction is that you're making a crappy general purpose framework, but you're making a really good problem specific framework that exactly fits the thing you're building. The reason those frameworks you list are so "bloated" is that their developers have spent so much time polishing them up and general-purpose-izing them so that Everybody can use them for Everything. Your thing is only for You to do Your Thing, so it can be much lighter and to the point.

Cthulhu_ 10y ago
> but you're making a really good problem specific framework that exactly fits the thing you're building. Except when you don't. A lot of people, when they realize they're building a framework, start over-engineering (YAGNI). Another issue is that they, for example, build a template renderer but miss a lot of edge cases, opening their application up for script injection and other such nasty things. Ten or so years ago, PHP had the same disease - people thinking they're hot shit, building their own frameworks, writing wrong tutorials on how to e.g. connect to a database because they thought they knew how that worked. This resulted in a huge amount of SQL injection issues, millions if not billions of hacked accounts, and billions in damages. TL;DR don't write your own framework, please.
- geebee 10y ago
  Id agree, but add my own plea: please dont write an spa if you dont need one. Yes I left that a bit ambiguous, but it is harder to manage and work witha rails and ember app than a reg'lear ol rails app. Thats cool if are genuinely getting something out of it. "Ember experiece" on your resume doesnt count. Except that it does, bummed, but i do understand.
- deleted 10y ago
  [deleted]
- dreistdreist 10y ago
  PHP did not have a useful package manager back then. It has now. Custom solution built on top of stable components > general purpose framework
mklim 10y ago
>The distinction is that you're making a crappy general purpose framework, but you're making a really good problem specific framework that exactly fits the thing you're building. Strongly disagree. Your hand-rolled framework is undocumented besides whatever comments you've put in your code, full of bugs besides whatever you've personally stumbled into, and lacks anything except the features you've needed thus far. It's a means-to-an-end to get the actual features you need done done, instead of built for its own sake and tested and polished for its own sake. The second your application grows in an unexpected way, you need to augment the entire framework to suit. If there's a bug, you can't search stackoverflow or the github page and just read the answer that 500 other people have found before you, and neither can anyone who has to take over the code after you and try to maintain it--you are the sole author, your internal comments and notes and email chains are all the documentation for the framework that exists in the entire world, there's no hope for the maintainers besides slogging through the source and discovering the solution from scratch. There is no cheerful dev community contributing PRs for the buggy edge cases that break your code on obscure browsers. There's no helpful blog posts out there on how to tweak it for performance optimization. It's all just you trying to maintain what really should be its own full time project while you're trying to build a real product on top of it at the same time. IME, hand-rolling your own framework as you're building a product gets you the bare minimum (read: extremely poor) mess of code that could possibly address your core use case, not something good for your specific problem. Using multiple libraries instead of monolithic frameworks I think is generally a good idea, depending on context--but completely hand-rolling your own framework from scratch while you're actively developing a product, no, I've never once seen this work well.
- treehau5 10y ago
  > The second your application grows in an unexpected way, you need to augment the entire framework to suit The second you need to do something your framework doesn't, the same rule applies. Frameworks are really good for covering most things, but almost everyone runs into that last 5-10% or so that it doesn't do. That ends up being the most difficult, in my experience.
  - jakub_g 10y ago
thewhitetulip 10y ago
I understand that rather than rolling out your own web framework we can just use existing frameworks. What are your thoughts about using libraries and not frameworks, like what what is popular with the Go language?
stickfigure 10y ago
you're making a really good problem specific framework You really aren't. Well -- I don't know you personally, but speaking statistically, your homegrown one-off framework only makes sense to you and will require a major rewrite to accommodate that feature you want to add next week. And you're going to spend all your time until then debugging a glitchy state transition.
matt4077 10y ago
Well, every app is a snowflake, but there's now a pretty good snowflake framework. Meaning: programming is all about abstractions, and if you hit the right level, all applications pretty much converge. Considering the manpower invested into today's frameworks and tooling, any single individual or small team doesn't stand a chance. Though the learning curve is much too steep at the moment. It's improving, mostly because 10-level deep callbacks are being replaced with promises/await/async, but especially the tooling is still a daunting challenge for many. There are now a few promising methods to get something running fast (create-react-app), but that seems to lead to opaque systems that usually work, but are prone to end up completely broken and incomprehensible when you're trying to customize them – because, for example, they do not validate their config files, use inconsistent naming, or deeply nested json where any deviation from the expected structure leads to silent failure.
matwood 10y ago
> The distinction is that you're making a crappy general purpose framework, but you're making a really good problem specific framework that exactly fits the thing you're building. But are you really? I'm not against rolling my own framework, but there needs to be very specifics reasons. The are so many reasons why using a popular framework is a good thing, that there have to be some very good reasons to roll my own. > Your thing is only for You to do Your Thing, so it can be much lighter and to the point. Unfortunately every time I have seen this reasoning used, it falls apart after starting. Rarely is software static, and instead it continues to grow. The custom framework may be lighter and to the point when you start and 6 months from now it is a bad copy of a common framework you could have just used off the shelf.
mwcampbell 10y ago
> Your thing is only for You to do Your Thing, so it can be much lighter and to the point. And also doesn't handle things that didn't occur to you, like accessibility. Some of that bloat is actually useful, even necessary, to someone.
deleted 10y ago
[deleted]

ofcapl_ 10y ago

I think in the best case scenario there should be a framework that doesn't need dedicated plugins - just using e.g. jQuery ones (because it has gazillions of them (plugins) already) - that would be wonderful

snarfy 10y ago

> To me, using something like Angular means I can harness the experience and expertise of dozens of superstar coders at Google You give them too much credit, and yourself not enough.

mwcampbell 10y ago
> You give them too much credit, and yourself not enough. On the contrary, the framework developers at Google, Facebook, etc. spend time on things that most web application developers do not. For example, accessibility for people with disabilities. If more web application developers would use these frameworks and follow the associated best practices, rather than all wanting to do things their own way, then maybe someday web applications will be accessible by default.

nojvek 10y ago

Disagree. Angular is a giant piece of bloated cheap that tries to do everything. I'm so glad someone wrote preact By using tools that do one thing and one thing very well it's easy to couple them together in interesting ways.