171–180 of 180 posts
Earlier quoted context omitted.
> I would be willing to give Ruby the point for MVC [...] I wouldn't.
Could you name a major web framework that implemented the MVC pattern prior to Rails?
I will however agree that Rails probably should take most of the responsibility/blame for really bringing MVC to the forefront of web development
Earlier quoted context omitted.
Could you name a major web framework that implemented the MVC pattern prior to Rails?
Spring? (Queue discussion on what is and isn't Real MVC(tm)) I will however agree that Rails probably should take most of the responsibility/blame for really bringing MVC to the forefront of web development
Earlier quoted context omitted.
The funny part is that technically Rails and Rails-inspired REST frameworks get it wrong. They're just exposing the server-side models via REST interface and the server-side models in turn expose the database's tables. That's REST by the books but not particularly useful unless all you're interested is exposing your database tables to the clients. Automagic REST APIs may be easier to do with "RESTful" MVC frameworks…
Here's a handy test to determine if two technological terms mean the same thing: are they used interchangeably? If I said to someone, "oh that looks like you need a SOAPful interface," would they assume that I meant RESTful? Probably not, since they're two different technologies. The move to REST was actually inspired by the perceived deficiencies in WSDL and SOAP. > The funny part is that technically Rails and Rails…
- https://en.wikipedia.org/wiki/Representational_state_transfe...
"The first edition of REST was developed between October 1994 and August 1995, primarily as a means for communicating Web concepts as we wrote the HTTP/1.0 specification and the initial HTTP/1.1 proposal. It was iteratively improved over the next five years and applied to various revisions and extensions of the Web protocol standards."
- Roy T, Fielding, Architectural Styles and the Design of Network-based Software Architectures, 2000
Most interesting is Roy's presentation at RailsConf Europe in 2007 (http://roy.gbiv.com/talks/200709_fielding_rest.pdf):
Use your brains!
- don’t design-by-buzzword
- don’t believe everything you read
Earlier quoted context omitted.
The funny part is that technically Rails and Rails-inspired REST frameworks get it wrong. They're just exposing the server-side models via REST interface and the server-side models in turn expose the database's tables. That's REST by the books but not particularly useful unless all you're interested is exposing your database tables to the clients. Automagic REST APIs may be easier to do with "RESTful" MVC frameworks…
Here's a handy test to determine if two technological terms mean the same thing: are they used interchangeably? If I said to someone, "oh that looks like you need a SOAPful interface," would they assume that I meant RESTful? Probably not, since they're two different technologies. The move to REST was actually inspired by the perceived deficiencies in WSDL and SOAP. > The funny part is that technically Rails and Rails…
I actually think this looks really good, but 3 things: 1. Why differentiate it from CoffeeScript so much? Why not call it DOMCoffeeScript or something? Are there any core language changes from CoffeeScript other than the tag features? 2. I'm not sure how I feel about the mixture of XML tag characters with HAML/Jade-like indentation. My gut instinct is to always look for a closing tag with XML/HTML. Why not use some k…
1. Because the semantics are quite different. See my other post. 2. It's still nice to separate the attributes from the content: "Foo" Why use a new syntax when everyone knows HTML/XML? 3. The lack of `var` in CoffeeScript is its worst feature ever IMO! Every time I write `someVariable = …` I'm terrified that I will accidentally overwrite a previous variable. Imba improves on JavaScript here and will correctly shadow…
But for 3... so you never use languages like Ruby or Python? Variable assignment shadowing is always possible in those languages, yet for seasoned developers, it tends not to be a real issue.
I actually think this looks really good, but 3 things: 1. Why differentiate it from CoffeeScript so much? Why not call it DOMCoffeeScript or something? Are there any core language changes from CoffeeScript other than the tag features? 2. I'm not sure how I feel about the mixture of XML tag characters with HAML/Jade-like indentation. My gut instinct is to always look for a closing tag with XML/HTML. Why not use some k…
Now they created a new "nonlocal"-keyword to cope with this but it wasn't added until version 3.0. https://www.python.org/dev/peps/pep-3104/ has a great summary of all this.
Earlier quoted context omitted.
> I would be willing to give Ruby the point for MVC [...] I wouldn't.
Could you name a major web framework that implemented the MVC pattern prior to Rails?
Earlier quoted context omitted.
Spring? (Queue discussion on what is and isn't Real MVC(tm)) I will however agree that Rails probably should take most of the responsibility/blame for really bringing MVC to the forefront of web development
Right you are! I didn't realize it had beaten Rails to the punch by a year. But yes, I will stand by my claim that Rails was responsible for popularizing the notion in the wider web development community.
"if Ruby and React had an indentation based lovechild, what would it look like?" Let me guess!... CoffeeScript?
Imba was actually forked from CoffeeScript three years ago. After the fork there's been a bunch changes, both in terms of adding tags, but also when it comes to the object model and variable scope. - Implicit calling: `foo.bar` calls `foo.bar()` and `foo.bar = 123` calls `foo.setBar(123)` - Objects have instance variables that's separate from the methods. Well, technically the instance variable `@bar` is just stored…
"if Ruby and React had an indentation based lovechild, what would it look like?" Let me guess!... CoffeeScript?
Imba was actually forked from CoffeeScript three years ago. After the fork there's been a bunch changes, both in terms of adding tags, but also when it comes to the object model and variable scope. - Implicit calling: `foo.bar` calls `foo.bar()` and `foo.bar = 123` calls `foo.setBar(123)` - Objects have instance variables that's separate from the methods. Well, technically the instance variable `@bar` is just stored…