DEADB17

https://git-scm.com/docs/git-check-ignore is useful to diagnose why a file is ignored

In the "Fundamentals"[1] course they use a table format for the design recipe that makes the correspondence between data and functions more obvious, and perhaps the JSP inspiration more evident.

[1] https://course.ccs.neu.edu/cs2500f17/design_recipe.html

The techniques are not mutually exclusive, it depends on the context. When you don't have a clear idea of the requirements starting "front to back" helps to understand and gather them while building something that validates them. For your example "back to front" sounds like a better fit.

Most of the complexity comes from state management and tracking data dependencies, not dom manipulation.

If you like keeping things light this library gives you a lot of bang for the buck:

https://github.com/MaiaVictor/PureState

It's similar to how pub/sub works but it does the topological sort that prevents data with diamond shaped dependencies from being triggered twice, in less than 500bytes minified (before zipping).

if you enjoyed this you might also find “A confession”[1] by L. Tolstoy interesting. I did.

[1] https://en.wikipedia.org/wiki/A_Confession

off topic, but HN is the last place I'd would expect to find a reference to Rudolf Steiner :)

plantuml is also text based and supports many types of diagrams: http://plantuml.com/gantt-diagram

There are tests to validate IE support. The intent is clearly there. Circumstantially this design decision is not met, but it is clearly a bug not some fundamental lack of support.

Please consider how your feedback might affect the people giving their effort to offer an option to the community.

Sorry @taeric, I can't reply to your post directly.

I do think that the intent of the producer is being communicated (unsafe to upgrade, safe to upgrade with new features, safe + automatic improvements).

I'm not disagreeing that "spec" adding more metadata to have better granularity and potentially reducing the amount of manual work is a good thing. But in the absence of it, "semantic versioning" is an improvement over safe and unsafe versions being indistinguishable.

I don't know about maven, but in NPM you can keep both. If you take away the limits of a particular implementation, I think that semantic versioning is a useful convention for the producer of an artifact to convey intent to the consumers.

Being screwed would be the case if the consumer of the artifact is forced to upgrade. i.e.: if versions cannot coexist in a code base.

Otherwise I think the information that they convey is useful:

PATCH: improvement or correction that does not affect the consumers expectation (safe improvement)

MINOR: additional features that may be useful directly to the consumer or its transitive dependencies (safe to upgrade)

MAJOR: No longer safe to upgrade automatically. The consumer may need to investigate further or stay with the previous MAJOR.

In any case it is useful information being conveyed. The consumer decides how to act on it.

Wouldn't changing the MAJOR version be equivalent to changing the namespace without altering the human memorable identifier of the package?

Understanding that changes in MINOR.PATCH are backwards compatible, is the difference between NAME MAJOR.MINOR.PATCH and NEW_NAME MINOR.PATCH significant? They look to me as just two different conventions.

I don't understand why he says semantic versioning does not work. In my experience (with NPM, not maven) it is very useful, adding meaning of intent by convention:

Given a version number MAJOR.MINOR.PATCH, increment the: MAJOR version when you make incompatible API changes, MINOR version when you add functionality in a backwards-compatible manner, and PATCH version when you make backwards-compatible bug fixes.

I got the impression that the issue was maven not being able to handle multiple versions of the same package/artifact, not in the convention.

I think that contrasting OOP with FP brings too many implicit assumptions to the discussion. The value of immutability, for example, seems to be orthogonal to the technique used to structure a computation and is more closely related to the problem to be solved.

In my opinion OO languages popularized the idea of having separate internal and external representations by providing language constructs that made it practical. But they also promoted the coupling of data with the methods to manipulate it -- this is not a necessary characteristic of OO but it is common in popular implementations. This association of data and methods turned out to be a limiting factor in the face of changing (maybe unknown) requirements. The flexibility of more dynamic run-times that allow to mutate this relationship during execution (monkey patching) was not a satisfactory solution as it inhibits static analysis. In my experience this is generally the main motivation when looking into alternatives.

Modeling computations as dynamic data threaded through a series of statically defined transformation seems like a sensible solution to the issue. It also brings additional benefits (e.g.: easier unit testing) and makes some constructs unnecessary (e.g.: implementation inheritance). This approach is commonly used in FP languages and I think is the main reason why they are contrasted as alternatives.

Since it's not always possible or desirable to re-write a project, sometimes the technique is dismissed because it is confused with the languages that favor it. The relative lack of resources explaining how to use FP techniques in OO languages doesn't help either.

Separating the techniques from the implementations has practical value and it allows evolving existing bodies of work.

After using browserify for a while now, I recently came across webpack (http://webpack.github.io/docs/what-is-webpack.html) which I'm finding more convenient and as efficient.

Advantages:

- requiring and pre-prosessing files other than js is easier

- ability to use AMD modules if you have to

- code splitting

It is, let me know if you want more info

which isn't really possible if you're rendering html in the server.

You can have a front-end web server that is also a client of the API server and keep the separation as if it were any other API client. This is the approach I'm taking in my current project since I have to support some obsolete browsers, but more generally it lends itself to a cleaner decoupled architecture