Hi everyone,
I try to implement the compression oriented way in my workflow. I have to admit that I love it when I program in C. But sometimes I have to code for the web and then I don't know how to incorporate the idea of compression oriented way because I'm so driven by the MVC architecture and some useful frameworks features like routers and so on.
I love the idea that functions operates on data and only that and not the OOP way but in the world wide web and its programming languages , I'm afraid I will not be be capable creating a complete website ( that needs to look professional ) without using OOP or frameworks.
I will be grateful if you guys, can share some opinions/ tips around that?
Thx a million !
I try to implement the compression oriented way in my workflow. I have to admit that I love it when I program in C. But sometimes I have to code for the web and then I don't know how to incorporate the idea of compression oriented way because I'm so driven by the MVC architecture and some useful frameworks features like routers and so on.
I love the idea that functions operates on data and only that and not the OOP way but in the world wide web and its programming languages , I'm afraid I will not be be capable creating a complete website ( that needs to look professional ) without using OOP or frameworks.
I will be grateful if you guys, can share some opinions/ tips around that?
Thx a million !
Edited by bewwys
on
Reason: Initial post
There are plenty of simple web server packages out there that I think work just fine with a compression-oriented style of programming. Fundamentally, all you need is for your server to respond to HTTP requests at particular URLs - and while the "classic" way is to use a bulky MVC framework, the actual problem is much smaller than that.
For example, take the built-in http package in my favorite web backend language, Go:
The extent of their HTTP "framework" is basically mapping routes to functions. You can of course render templates, introduce "middleware" by putting common functions in your handlers (wrapper functions or otherwise), or do anything else your server needs, without any OOP bloat.
What you really don't need is the OOP stuff. It's no more difficult to separate your data from your behavior in web programming than in any other discipline - you just have to find a server package that doesn't force a lot of extra structure on you. "Routing" is still useful (it's just parsing URLs), "middleware" is still useful (it's just applying functions to the request/response), but you can do those things without an aggressive or opinionated framework.
For example, take the built-in http package in my favorite web backend language, Go:
1 2 3 | http.HandleFunc("/", func (w http.ResponseWriter, r *http.Request) { fmt.Fprintf(w, "Welcome to my website!") }) |
The extent of their HTTP "framework" is basically mapping routes to functions. You can of course render templates, introduce "middleware" by putting common functions in your handlers (wrapper functions or otherwise), or do anything else your server needs, without any OOP bloat.
What you really don't need is the OOP stuff. It's no more difficult to separate your data from your behavior in web programming than in any other discipline - you just have to find a server package that doesn't force a lot of extra structure on you. "Routing" is still useful (it's just parsing URLs), "middleware" is still useful (it's just applying functions to the request/response), but you can do those things without an aggressive or opinionated framework.
As Ben stated, it is entirely possible to use COP with web stuff. Server side I don't think that the idea of MVC is bad, as web problems often fall into 'get something from a database and put it into a template', most implementations of it are hugely over-complicated though.
Taking this approach does seem to be against the grain overall, and tends to demand a lot more work.
Taking this approach does seem to be against the grain overall, and tends to demand a lot more work.