Hacker News new | past | comments | ask | show | jobs | submit login

I seriously think this is some sort of parody of JS. Really? A new framework every week?



As someone who mostly codes in Python, I don't understand, why JS gets new framework so often. What is the reason behind? Is Javascript makes thing easy to develop a new framework? Why doesn't Python get new framework so often?


Ahh. You just haven't been around Python for long enough. Python used to get new server framework every other week. There was a Cambrian Explosion of them at one stage. Then it settled down. Javascript is still evolving. React has just kicked off a whole new iteration by putting the reactive/functional/immutable paradigm firmly on the agenda. That's going to take a couple of years to play out.

BTW, If you want to see what that combination looks like in a more suited language then look towards ClojureScript or Elm.


My personal theory is that it is because

    * JS is possibly the largest programming language community in the world
    * There are a lot of shortcomings in "the web platform" for app-style development
    * Most JS developers are primarily developers in another language with a stronger culture and set of ideas/idioms
Combine these things and you get .NET developers creating C# flavored JS frameworks, Ruby developers creating Railsish frameworks, etc. Then you have interactions of those ideas, where it's like C# and Ruby had a baby as a JavaScript MVC framework. :-)

It's basically the cambrian explosion.


Is there any Pythonish JS framework?


There are clones for most popular template rendering systems, and would be surprised if there wasn't similar as a whole application framework.

Do a search of https://npmjs.com/ for a framework you want a synonym to, and you will probably find it.

For me, some tools simple ring better in the JS way than others... if it's too cobbled, and relies on strange markup behaviors I like it less. If it's really class centric I tend to like it less, though ES7 classes and React isn't too bad. It just depends on your likes.

I really don't like seeing certain patterns in JS (factories and di/ioc) as they simply aren't needed and only add complexity.


Server code is spread across different languages. But every webdev is forced to use JS on the client. It's the sheer amount of people using this language.


It because package management in JS is complete garbage. I can't believe people actually like using Bower or Browserify or JSPM or any of it. While NPM for Node has some scaling problems, at least it just works for the simple cases. I've never not had problems with the client-side JS package systems and managers.

So package adoption is hard because of this. If you make it a pain for implementing developers to use your code, they're more likely to just write their own code.

That's why I think the old style ala jQuery or Google Maps API of packaging everything manually as just namespacing-objects still makes the most sense, with the fewest tradeoffs. You give the user a single, minified JS file to either copy or reference on your CDN. It's a least-common-denominator solution and it lets the implementing developer figure out how to fit it into their workflow.


Just use npm dude :p </brogrammer>

Seriously though, it's a non-problem now. There is no way I'd go back to anything else. Webpack and browserify are the only way to go. </religion>

Yes, there is a certain purism to doing your own modules and IIFEs and JS, but it's like claiming that code is only fast when it's asm. </realcoders>

Besides it can all be optimised out if you add the closure compiler plus relevant comments </nobodyactuallydoesthat>


In general I just use npm... I don't use bower or jspm... for that matter, I don't think browserify where needed is so bad.. there's also options with babeljs, which I'm liking more and more.

A base set of packages, for your external functionality, your core (shared functionality) and the rest makes a lot of sense, and isn't that hard to do. In the end it's pretty easy to reason about, and with sourcemaps and better build tools it's easy to use. Though having to have a watcher or build process when JS changes takes some getting used to... if you're used to compiling server code, it really isn't bad...


I think it's because it's relatively straightforward to accomplish. These guys can work on creating stuff like this and put on their portfolio they created "Noun.js" and it 'looks good' to those not in the developer world and knowing a new one is out every week.

I consider them somewhat fluffy and learn just to say nice job and move on.


> Why doesn't Python get new framework so often?

It definitely did with django, pylons, flask, turbogears, web2py, . . . I didn't know which way to turn.

PHP had the same thing with cakePHP, symphony, drupal, and so forth. I remember rolling my own using smarty long ago, because I couldn't decide.


I've been coding JS for a while now, and it personally feels having imposter syndrome most of the time.

It's easy to get into making/sharing something, but has no (strict) guidelines on how things are structured or work. So you have countless ways to do one thing.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: