6 ms·

Having worked with many different languages and frameworks over the years, I have to disagree: when creating web applications, starting from scratch or from a m

Having worked with many different languages and frameworks over the years, I have to disagree: when creating web applications, starting from scratch or from a minimal base is massively slower, more error prone and less safe than starting from a well developed and maintained framework, where so many of the things you're going to need have already been solved and battle tested.

thrownaway954 8y ago
"more error prone and less safe" right there... if I could vote you up a thousand times, I would. I can place a bet that most home grown apps have no security measures against CSRF or XSS in place.
- sheeshkebab 8y ago
  Most modern apps use api/json based endpoints where csrf is not needed (cookies are no longer used for auth) and xss is massively simplified since html is rarely returned by backend. In other words most web frameworks that help with rendering html on the server and writing forms to database are not needed either.
- klodolph 8y ago
  CRSF is not an issue for JSON API endpoints, since cross-origin requests are disabled by default. XSS in my experience is best solved by a reasonable templating language. The same way you don't use string concatenation to insert user data into HTML documents, you don't use string concatenation to insert user data into SQL queries. Frameworks don't add anything here that you don't already have, and a lot of frameworks let you choose your templating system anyway. This was a big reason to use frameworks in past days, though.
imtringued 8y ago
I prefer frameworks but sometimes there is a lack of fine grained escape hatches. Feature X covers 99% of the things I need. To get to 100% I have to stop using feature X and do everything myself. The solution to this problem is to make feature X more flexible, not to rip out the rest of the framework too.
lmm 8y ago
A summary of my experience would be: libraries are good, frameworks are bad. (Indeed possibly the best "framework" I ever used was TurboGears which is very deliberately just a collection of dedicated libraries, all of which you can replace piecemeal as and when you need to). Rails raised the bar for how little custom configuration should be necessary to do a simple, straightforward thing. But it turns out being a framework is not integral to that; modern libraries have been able to adopt the "opinionated" (which seems to be just a fancy term for having sensible defaults) approach of rails without having to grow into all-encompassing frameworks.
- monkeynotes 8y ago
  Can you give an example of a collection of libraries that you would consider would compete with Rails?
  - lmm 8y ago
    On a broad level, Turbogears is such a thing. (On an even broader level, so is my current preferred stack which is something like: Wicket, Akka-Http, Circe, Hibernate, Liquibase, and Scala's native ways of doing DI). If you're asking about Ruby specifically I'm not current enough to answer.
  - deleted 8y ago
    [deleted]
- toasterlovin 8y ago
  You know that Rails is a collection of libraries that can pretty much all be replaced with the alternative of your choice, right?
  - lmm 8y ago
    Up to a point. In my experience there is limited support for e.g. using "mismatched" versions of different parts of it.
    - 8y ago
smt88 8y ago
> starting from scratch or from a minimal base is massively slower This isn't the better alternative to frameworks. The better alternative is using libraries and optionally a bootstrap code generator, which is not at all "starting from scratch". The major difference is that you tell the libraries how to work together, rather than the framework telling you how to work. Some frameworks become like a terrible DSL that you could never translate back into idiomatic code.
- monkeynotes 8y ago
  > you tell the libraries how to work together Doesn't this just become a bunch of decisions and team cognitive load you have to deal with?
  - smt88 8y ago
    Less than you'd think. The team architect should set up the project structure, not a committew. Most languages have idiomatic conventions for writing framework-less code, so it's not going to look totally unique when they're done.
  - klodolph 8y ago
    With frameworks you need a mental model of how the framework works. With libraries, you need a mental model of how your code works. On the balance of things, I would say that libraries often (not always) have less cognitive load here. If you need the best library for the job, you can spend as much time as you like picking one. It's a matter of restraint to simply not spend that effort, and instead just pick a library because it meets your needs (without spending more than a moment evaluating whether it is better or worse than alternatives).
- danmaz74 8y ago
  > > starting from scratch or from a minimal base is massively slower > This isn't the better alternative to frameworks. I was specifically answering to the remark from the what was at the time the top comment, saying that starting from Rack is the best approach.
gumcreme 8y ago
> when creating web applications, starting from scratch or from a minimal base is massively slower Because every web app is the same CRUD app, right? Things evolved the last years, I build you any app as fast and create more maintainable code with my stack which consists of small libs than any Rails dev. Don't forget that also a lot of work moved to the front-end, so your daddy's Rails won't help you on that anymore. Web apps are not developed like ten years ago.
mikekchar 8y ago
It certainly can be. It doesn't have to be thought. It really depends a lot on your team. I've worked on teams where building large scale, but minimal, well tested systems was their bread and butter. I've also worked on teams where hooking up existing frameworks was what they were comfortable with and any footstep taken outside of that activity was marked with considerable rancour. Not invented here syndrome is also a real thing and sometimes people sit there building "game engines" instead of "games" ;-) On the other hand "Invented here" syndrome is also a real thing and sometimes people completely panic when faced with the thought of writing something novel. You need to go with your team. I think it was Alan Kay who summed it up best: If your team is capable of building a compiler, you must build a compiler. If your team is not capable of building a compiler, you must not build a compiler. That matches my experience exactly ;-)

thrownaway954 8y ago

"more error prone and less safe" right there... if I could vote you up a thousand times, I would. I can place a bet that most home grown apps have no security measures against CSRF or XSS in place.

sheeshkebab 8y ago
Most modern apps use api/json based endpoints where csrf is not needed (cookies are no longer used for auth) and xss is massively simplified since html is rarely returned by backend. In other words most web frameworks that help with rendering html on the server and writing forms to database are not needed either.
klodolph 8y ago
CRSF is not an issue for JSON API endpoints, since cross-origin requests are disabled by default. XSS in my experience is best solved by a reasonable templating language. The same way you don't use string concatenation to insert user data into HTML documents, you don't use string concatenation to insert user data into SQL queries. Frameworks don't add anything here that you don't already have, and a lot of frameworks let you choose your templating system anyway. This was a big reason to use frameworks in past days, though.

imtringued 8y ago

I prefer frameworks but sometimes there is a lack of fine grained escape hatches. Feature X covers 99% of the things I need. To get to 100% I have to stop using feature X and do everything myself. The solution to this problem is to make feature X more flexible, not to rip out the rest of the framework too.

lmm 8y ago

A summary of my experience would be: libraries are good, frameworks are bad. (Indeed possibly the best "framework" I ever used was TurboGears which is very deliberately just a collection of dedicated libraries, all of which you can replace piecemeal as and when you need to). Rails raised the bar for how little custom configuration should be necessary to do a simple, straightforward thing. But it turns out being a framework is not integral to that; modern libraries have been able to adopt the "opinionated" (which seems to be just a fancy term for having sensible defaults) approach of rails without having to grow into all-encompassing frameworks.

monkeynotes 8y ago
Can you give an example of a collection of libraries that you would consider would compete with Rails?
- lmm 8y ago
  On a broad level, Turbogears is such a thing. (On an even broader level, so is my current preferred stack which is something like: Wicket, Akka-Http, Circe, Hibernate, Liquibase, and Scala's native ways of doing DI). If you're asking about Ruby specifically I'm not current enough to answer.
- deleted 8y ago
  [deleted]
toasterlovin 8y ago
You know that Rails is a collection of libraries that can pretty much all be replaced with the alternative of your choice, right?
- lmm 8y ago
  Up to a point. In my experience there is limited support for e.g. using "mismatched" versions of different parts of it.
  - 8y ago

smt88 8y ago

> starting from scratch or from a minimal base is massively slower This isn't the better alternative to frameworks. The better alternative is using libraries and optionally a bootstrap code generator, which is not at all "starting from scratch". The major difference is that you tell the libraries how to work together, rather than the framework telling you how to work. Some frameworks become like a terrible DSL that you could never translate back into idiomatic code.

monkeynotes 8y ago
> you tell the libraries how to work together Doesn't this just become a bunch of decisions and team cognitive load you have to deal with?
- smt88 8y ago
  Less than you'd think. The team architect should set up the project structure, not a committew. Most languages have idiomatic conventions for writing framework-less code, so it's not going to look totally unique when they're done.
- klodolph 8y ago
  With frameworks you need a mental model of how the framework works. With libraries, you need a mental model of how your code works. On the balance of things, I would say that libraries often (not always) have less cognitive load here. If you need the best library for the job, you can spend as much time as you like picking one. It's a matter of restraint to simply not spend that effort, and instead just pick a library because it meets your needs (without spending more than a moment evaluating whether it is better or worse than alternatives).
danmaz74 8y ago
> > starting from scratch or from a minimal base is massively slower > This isn't the better alternative to frameworks. I was specifically answering to the remark from the what was at the time the top comment, saying that starting from Rack is the best approach.

gumcreme 8y ago

> when creating web applications, starting from scratch or from a minimal base is massively slower Because every web app is the same CRUD app, right? Things evolved the last years, I build you any app as fast and create more maintainable code with my stack which consists of small libs than any Rails dev. Don't forget that also a lot of work moved to the front-end, so your daddy's Rails won't help you on that anymore. Web apps are not developed like ten years ago.

mikekchar 8y ago

It certainly can be. It doesn't have to be thought. It really depends a lot on your team. I've worked on teams where building large scale, but minimal, well tested systems was their bread and butter. I've also worked on teams where hooking up existing frameworks was what they were comfortable with and any footstep taken outside of that activity was marked with considerable rancour. Not invented here syndrome is also a real thing and sometimes people sit there building "game engines" instead of "games" ;-) On the other hand "Invented here" syndrome is also a real thing and sometimes people completely panic when faced with the thought of writing something novel. You need to go with your team. I think it was Alan Kay who summed it up best: If your team is capable of building a compiler, you must build a compiler. If your team is not capable of building a compiler, you must not build a compiler. That matches my experience exactly ;-)