Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Choosing a Web Framework/Language Combo for the Next Decade

jacquesmattheij.com

Post reply on HN
Print view View original

91–100 of 228 posts

Re: Choosing a Web Framework/Language Combo for the Next Decade

#91

Post by sehr »

camus2 wrote: post #76
fenguin wrote: post #21

"JavaScript web frameworks seem to have a half-life of about 6 months..." Express [1] has been the dominant framework for Node.js since 2009-2010. What frameworks are you talking about? [1] https://github.com/visionmedia/express

I wouldnt consider Express as a framework. It's just a router and a few middleware. Hapi or Actionhero are frameworks though rest ones.Express is definetly not a framework,it doesnt do anything much. Writing Spring like, Symfony like frameworks is hard in nodejs. Libs are bad,often tightly coupled,and frankly nobody's maintaining nothing on the long run.

> Express is definetly not a framework,it doesnt do anything much.

Consider that your definition of a framework may be different from others.

Re: Choosing a Web Framework/Language Combo for the Next Decade

#92

Post by zmmmmm »

jacquesm wrote: post #88
higherpurpose wrote: post #79

Google could give a huge boost in confidence in Go, tomorrow (or rather within 2 years) - just make Go the official main language to use for writing Android apps and start deprecating Java. Once it does that, I don't think there will be any doubt in anyone's mind that Go has less chance of survival than say Java. In fact, Java will immediately lose confidence once Android drops Java (in a reasonable 3-5 year timefram…

Are you suggesting that the Go language would be retargeted to the VM? Or that Android apps would be compiled into binaries executed without a VM? Either way, fascinating idea, and it would be a good way to settle the Google/Oracle dispute once and for all. If they choose the second path (security will be a huge concern) they might even pick up a nice speed boost too.

I've secretly hoped Google would be going down this path for a long time but sadly no evidence of it.

> Or that Android apps would be compiled into binaries executed without a VM?

What I imagine in my Android-Go-fantasy is something like NaCl - your code compiles to native code, but a subset of provably safe native code ... so sort of a best of both worlds.

Re: Choosing a Web Framework/Language Combo for the Next Decade

#93

Post by BSousa »

gexla wrote: post #54

Might as well go with the one which sparked the wave which inspired most of these. Rails is pretty much the premier MVC framework. If you are going to go MVC, go with Rails. If we are looking for an alternative to Rails, then we are probably looking for an alternative to MVC, and none of these mentioned choices fit the bill. I wonder when the day will come that we finally get sick of recreating all the libraries that…

For all the mentions of MVC in your post, you should probably realize that Rails isn't really MVC. Some of the new JS frameworks are actually MVC, but Rails it is not. (Rails is more Model2: http://en.wikipedia.org/wiki/Model2 than true MVC).

Re: Choosing a Web Framework/Language Combo for the Next Decade

#94

Post by lazyjones »

DennisP wrote: post #90
lazyjones wrote: post #59

Rather than sloppily relying on hearsay, popularity and Googling, the suitability of web frameworks could be tested in competitions like https://www.plat-forms.org ... I wish more people would participate there, the results are somewhat surprising (and of course take into account the skill of the developers).

Maybe people don't get involved because it's hard to figure out the results. I see a graph labeled "team A, B, C..." and no key to which team is which. What am I missing?

The website is bad indeed, it seems to be an understaffed academic project, but the concept is worth imitating IMO.

Re: Choosing a Web Framework/Language Combo for the Next Decade

#95

Post by rfergie »

arethuza wrote: post #70
tikhonj wrote: post #17

I (naturally) think that the article's summarily dismissing Haskell is unfortunate. It's probably just the result of poor PR on Haskell's part. Haskell is not only for surpassingly intelligent people, or even optimized for them. If anything, it's the opposite: one of its core tenants is that we're not smart enough to reason about our programs in most languages. Much of the design work focuses on unloading complexity…

Out of interest, what would you say are the kinds of bugs that using something like Haskell helps you avoid? I've had a look at Haskell before and while all the individual parts looked reasonable I struggled to understand both what an application would look like at a high level and what the inherent advantages are (not saying there aren't any - just that they didn't jump out to me). In most languages I have learned I…

http://programmers.stackexchange.com/questions/215482/what-a... has a good list of the type (no pun intended) of error that type systems can prevent

Re: Choosing a Web Framework/Language Combo for the Next Decade

#96

Post by davidw »

zimpenfish wrote: post #82
davidw wrote: post #62

> TCL is not really web suitable (though it’s been done) I don't use Tcl (not TCL!) anymore myself, but it'd be more honest to say that it's not that popular these days or not a language you happen to like. This is built with Tcl just fine: http://flightaware.com/ With that out of the way, I think that was a good read, and a reasonable process. It's fair to be a bit subjective about some things, because... we're huma…

AOL ran on AOLServer[1][2] (TCL + embedded C bits) for many years, I believe, quite happily. [1] http://www.aolserver.com [2] http://philip.greenspun.com/wtr/aolserver/introduction-1.htm...

Yes, I was going to mention that too - it's a bit ironic saying that Tcl (not TCL!) is not ok for the web when it was used for some of the first serious dynamic content web systems.

Re: Choosing a Web Framework/Language Combo for the Next Decade

#97

Post by rubinelli »

collyw wrote: post #84
netcan wrote: post #65

Since the exercise is framed this way (for the next decade), It might by interesting to try it from the perspective of 2004. IE, if you made a decision this way in 2004, how wrong/right would it have been now that the decade is over?

We would all be writing Java applets, no?

Java applets were already dead by then. The new hotness was JSF + Hibernate, and ASP.Net WebForms on the Microsoft side.

Re: Choosing a Web Framework/Language Combo for the Next Decade

#98

Post by jacquesm »

davidw wrote: post #96
zimpenfish wrote: post #82

Earlier quoted context omitted.

AOL ran on AOLServer[1][2] (TCL + embedded C bits) for many years, I believe, quite happily. [1] http://www.aolserver.com [2] http://philip.greenspun.com/wtr/aolserver/introduction-1.htm...

Yes, I was going to mention that too - it's a bit ironic saying that Tcl ( not TCL!) is not ok for the web when it was used for some of the first serious dynamic content web systems.

I thought I wrote 'modern web'. I'll update if I got that wrong, and I'll update the spelling too.

Edit: good catch David, I used modern web in one instance and 'web' in two others. Changed that to be consistent. TcL now properly spelled. Have a well deserved upvote :)

Re: Choosing a Web Framework/Language Combo for the Next Decade

#99

Post by mtrimpe »

tikhonj wrote: post #17

I (naturally) think that the article's summarily dismissing Haskell is unfortunate. It's probably just the result of poor PR on Haskell's part. Haskell is not only for surpassingly intelligent people, or even optimized for them. If anything, it's the opposite: one of its core tenants is that we're not smart enough to reason about our programs in most languages. Much of the design work focuses on unloading complexity…

I'm all for trying something unfamiliar, and I could even argue for Haskell that way, but from a different angle.

I would say that adopting a language for the next 10 years that doesn't have purely functional data structures at its core is a fool's errand.

Persistent data structures, i.e. efficiently storing every version of your data structure, is the natural reflection of the new reality in computing where:

  * storage is cheap
  * random reads are cheap
  * random writes are expensive
  * serial writes are cheap
Whether you adopt this through Haskell, Clojure, scala or even Bloom e.a. is fairly inconsequential.

What will matter is that persistent data structures will inevitable become commonplace over the next decade and that techniques for leveraging it (such as functional reactive programming) will be adopted in one form or another.

@jacquesm: I live in Amsterdam so I can try to explain it to you in person once; virtually everyone still underestimates the impact this will have and (or perhaps because) it's very difficult to get that across in writing.

Re: Choosing a Web Framework/Language Combo for the Next Decade

#100

Post by goldfeld »

jacquesm wrote: post #86
grayrest wrote: post #61

Earlier quoted context omitted.

If you arbitrarily reject everything unfamiliar then filter the remainder for stability you wind up with unremarkable stuff that will get the job done. There are better ways to write web apps but you're not going to find them following the process outlined in the post.

Boring unremarkable stuff that gets the job done sounds great to me. Sexy, new, hot, flashy are exactly what I'm trying to avoid getting sucked in to (though, believe me I can feel the draw). The life-cycle of the software underpinning what I build is as important or even more important than whether or not it is 'the best way' to do something today. Because that best way is the bleeding edge and the day after tomorro…

I was really drawn to the title of your post because that's just what I have done--well, over the last few months--and I went with Clojure. I want to absolutely focus now and I can see the momentum is gonna take me for at least the next 10 years. I never rode the Rails train and after becoming a functional programming believer I'm kinda glad I didn't in retrospect, but I had always been envious of people who did make that decision to become good at a stack. I agree with you that the error exploding in Clojure is not nice, but to me it makes up for it in being on top of both Java and JavaScript (having been a JS dev previously, but being entirely tired of the convulsion of frameworks and build tools and module systems.)

It's a lisp that, as opposed to Lisp and Scheme, is not fragmented and seems to have mostly a healthy, united community. I see amazingly smart people, and so many of them, pushing Clojure forward (Rich Hickey, Stuart Sierra, David Nolen, Chas Emerick to name a few) and yet it's more approachable than Haskell. And I think these people will eventually find good, standardized solutions for things like the awfully ugly stacktraces.

Clojure doesn't really have a 'framework', and I like it that it's really composable in that sense. But things like Ring and Compojure are lightweight no-brainers, much like Rails is a heavyweight no-brainer for Ruby. What I want to say is, unlike JavaScript, after having picked Clojure as the language, the choice of everything else is mostly always a no-brainer (e.g. leiningen, core.async, enlive/hiccup, maybe Om soon.) And that really pleases my choice-avert brain.

Post reply on HN