3 ms·

As a counter point, are you sure web dev is the complex thing, or does it just seem complex because you're dealing with these massive gnarly frameworks that hid

As a counter point, are you sure web dev is the complex thing, or does it just seem complex because you're dealing with these massive gnarly frameworks that hide thousands of lines of code behind seemingly simple facades that perform incomprehensible magic? I think the mention in the article of the User.Create(params[:name]) one liner is really instructive. Creating a user is one of the most important things you're going to do in an application! The business logic rules are incredibly important, the security implications are huge, everything. Trying to make it "easy" is ridiculous, because as a developer, you should be thinking about these things. That's the kind of thing that should contain absolutely zero magic, the logic should be upfront and visible. I've worked as a web dev, and I've also worked outside of web development, and the number one thing that drove me insane doing web development was never knowing if any one line of code was doing some severe amount of impossible-to-debug magic. I'd rather just write javascript against the browser APIs with a lightweight http server. As far as I can tell, the vast majority of frameworks aren't really about providing functionality, they're thought experiments in how to write software. That's fine, but they should bill it as such. I'm not going to say web development is easy, there are parts that are legitimately difficult on their own accord, but I think the web development community has made things massively harder on themselves by pretending all these abstractions are actually simplifying the task they've set out to do.

aantix 10y ago
>because as a developer, you should be thinking about these >things. That's the kind of thing that should contain >absolutely zero magic, the logic should be upfront and visible No, you shouldn't be thinking about these things. Because you'll get them wrong. Are you really going to account for all security cases? Are you really going to account for all data coercion coming to/from the db? And even if you do, why go through the pain of those cases when there's a community of thousands of other developers, some of which have probably solved it infinitely better? Eventually, we have to get shit done. The only code that is worth something is code that serves others. Eventually we have to pick some abstractions so that we can get on with the show.
- code_sloth 10y ago
  > No, you shouldn't be thinking about these things. Because you'll get them wrong. "Magic" is good for beginners, because there's just too much they don't know. Not thinking about all these things because the community of thousands should have done it better I did, is just lazy. This is the kind of thinking that leads to unnecessary layers of abstraction and bloat.
  - dkrich 10y ago
    So do you roll your own OS? Payment processing system? Web server on your own hardware? Just because you aren't hand-coding it doesn't make it "magic" or "lazy," it makes it efficient. I'm perfectly happy to use Bootstrap for my web application's styling because they've handled most of the exact same styling problems I will have to, and quite well. I am quite confident I could replicate a lot of that functionality every time I needed to build a web app, but why would I do that when it's already been done and I can focus on other problems? As an aside I'm curious why you think that "magic" is good for beginners. When you don't have a clue what is going on at all, you really should spend some time learning what happens when you create a user via ActiveRecord, which can easily be done if you study the log files for a bit and read the Rails documentation. Once you are comfortable with what's going on, then you can use the framework to auto-generate code for you.
    - jimbokun 10y ago
      The point is not about "hand-coding" at all. It's about reading the code, and having a good mental model of what is happening. This is the point Rich Hickey tried to drive home with his talk "Simple Made Easy". https://www.infoq.com/presentations/Simple-Made-Easy https://www.infoq.com/presentations/Simple-Made-Easy If you are a developer and haven't watched this yet, you really, really should. Very important distinction to keep in mind any time you are writing software. Haven't read the Active Record source code, but would be interesting to find out where it falls on the "Simple vs. Easy" continuum.
      - spacemanmatt 10y ago
dkrich 10y ago
What's missing for me from this whole discussion is the allowance that both methods can be correct. Use case: you're a solo developer and you need to build a proof of concept web application based on a fairly complex set of requirements. You probably want to use a framework like Rails and focus your time 100% on the specific project requirements, and use the framework to generate the common parts of the web app for you. Another use case: you're on a large, multi-year project for a huge client where each developer has his/her own specialty area. Here it may well make sense to go with a Java Enterprise app and wire your own persistence layer or write your own SQL queries. The mantra of Rails has always been "don't repeat yourself." Don't waste time rebuilding the same 90% skeleton every time you need a CRUD app with a postgres database. Want absolute granular control over all parts of your application? Then almost by definition, you really don't need a framework. So great, don't use one and roll your own web app from the ground up. But there are many times it makes complete sense.

aantix 10y ago

>because as a developer, you should be thinking about these >things. That's the kind of thing that should contain >absolutely zero magic, the logic should be upfront and visible No, you shouldn't be thinking about these things. Because you'll get them wrong. Are you really going to account for all security cases? Are you really going to account for all data coercion coming to/from the db? And even if you do, why go through the pain of those cases when there's a community of thousands of other developers, some of which have probably solved it infinitely better? Eventually, we have to get shit done. The only code that is worth something is code that serves others. Eventually we have to pick some abstractions so that we can get on with the show.

code_sloth 10y ago
> No, you shouldn't be thinking about these things. Because you'll get them wrong. "Magic" is good for beginners, because there's just too much they don't know. Not thinking about all these things because the community of thousands should have done it better I did, is just lazy. This is the kind of thinking that leads to unnecessary layers of abstraction and bloat.
- dkrich 10y ago
  So do you roll your own OS? Payment processing system? Web server on your own hardware? Just because you aren't hand-coding it doesn't make it "magic" or "lazy," it makes it efficient. I'm perfectly happy to use Bootstrap for my web application's styling because they've handled most of the exact same styling problems I will have to, and quite well. I am quite confident I could replicate a lot of that functionality every time I needed to build a web app, but why would I do that when it's already been done and I can focus on other problems? As an aside I'm curious why you think that "magic" is good for beginners. When you don't have a clue what is going on at all, you really should spend some time learning what happens when you create a user via ActiveRecord, which can easily be done if you study the log files for a bit and read the Rails documentation. Once you are comfortable with what's going on, then you can use the framework to auto-generate code for you.
  - jimbokun 10y ago
    The point is not about "hand-coding" at all. It's about reading the code, and having a good mental model of what is happening. This is the point Rich Hickey tried to drive home with his talk "Simple Made Easy". https://www.infoq.com/presentations/Simple-Made-Easy https://www.infoq.com/presentations/Simple-Made-Easy If you are a developer and haven't watched this yet, you really, really should. Very important distinction to keep in mind any time you are writing software. Haven't read the Active Record source code, but would be interesting to find out where it falls on the "Simple vs. Easy" continuum.
    - spacemanmatt 10y ago

dkrich 10y ago

What's missing for me from this whole discussion is the allowance that both methods can be correct. Use case: you're a solo developer and you need to build a proof of concept web application based on a fairly complex set of requirements. You probably want to use a framework like Rails and focus your time 100% on the specific project requirements, and use the framework to generate the common parts of the web app for you. Another use case: you're on a large, multi-year project for a huge client where each developer has his/her own specialty area. Here it may well make sense to go with a Java Enterprise app and wire your own persistence layer or write your own SQL queries. The mantra of Rails has always been "don't repeat yourself." Don't waste time rebuilding the same 90% skeleton every time you need a CRUD app with a postgres database. Want absolute granular control over all parts of your application? Then almost by definition, you really don't need a framework. So great, don't use one and roll your own web app from the ground up. But there are many times it makes complete sense.