Hacker News new | ask | show | jobs
by krapp 3952 days ago
>Instead of writing code in programing language we move into xml/yaml direction and hundreds of weird config files.

Blame this partially on the weird phenomenon of programmers refusing to touch languages they consider aesthetically ugly. Javascript? CSS? Ick. Much better to pile on a build system to compile those languages from another language that looks kind of Ruby. HTML? Ew - no significant whitespace. Let's generate HTML from something that looks and acts like Python.

But, snark aside, I think it's a good thing if a framework can be agnostic about the kind of configuration syntax it uses, although that in and of itself implies some minimal complexity. Whatever choices the developers make about this, of course, amount to personal preference. Heck, I prefer INI files for configuration.

>Even small website often requires hundreds of megabytes of dependencies

That depends on the language and framework you're using. And how small you consider a "small" website.

Unfortunately (in my opinion, with which I know others will disagree) frameworks tend to want to do too much, and as such tend to bloat into vast, overly complex attempts at reinventing the wheel, the chassis, the transmission, the bumpers and deciding what kind of air freshener you should want hanging from the mirror. I would prefer a framework not have a templating library or ORM or code generators baked in at all. Those should be implementation specific decisions. Rather, a framework should manage dependencies, routing, global config, responses, have some hooks to allow extensibility - the basics. If I want more, I can pick libraries for that.

1 comments

The problem with JS is not that is it aesthetically ugly, but the lack of a decent type system. The fact you can add whatever data you like to any object, and the object itself could be the data or a promise to return the data, and you cannot verify that the caller and callee are compatiable at compile time is asking for so much trouble. Let alone the nasty implicit type casting, two types of null value, truthy values etc. It is a real mess for the programmer who likes to reason about their code.
It is really difficult to explain the benefits of static analysis and type safety to people who only work in dynamically typed languages.

The JS community is just now being introduced to compilers, and there is significant push back and lots of people crying for "simpler age". I think it will be a while (if ever) until languages like closurescript, scalajs, & typescript start seeing widespread adoption outside of their fiefdoms (google, fb, microsoft).

If you are interested in a typesafe universal js ( or isomorphic js, whatever we are calling it now ) proof of concept you can check out this project using scalajs and scala-js react.

http://ochrons.github.io/scalajs-spa-tutorial/index.html

It depends what you are doing. If you have 10 lines of JS then probably no need for an abstraction. However if you have 1000s of lines of client code, then using a purescript or similar can be very beneficial to maintainability and provability of the code.

But there is a learning curve and unlike Haskell where you just know have to know the language, you have to know both the JS quirks and the compiler's quirks too. It is a leaky abstraction. This is the problem I have with a lot of the compile-to-android frameworks vs. just putting with with Java.