Hacker News Reader

> I am working on a larger .NET web application in my day job... and it requires things like.. Typescript + typings files, Webpack/Gulp/Grunt/etc. and therefore Node.js and NPM, NuGet, .NET Framework, onion architecture, front-end framework (Angular, or React, or..), Entity Framework, multiple databases, web services/web API, ASP.NET MVC.. I mean, it's just crazy if you step back and think about it.

All long as all the tools and pipelines work flawlessly it's painless.

As soon as something goes wrong, if you are not a specialist or have a deep understanding of the inner-working of all these it actually hinders productivity.

What if Webpack doesn't work as expected because you mis-configured it? what if there is a bug in AngularJS and you're not capable of fixing it yourself? What if Entity framework doesn't support a specific use case/feature of your DB?

While in a professional environment implementing the domain is already a lot of work and people want the rest to be coded fast by using ready-made solutions, each new component, framework should be carefully vetted, adding a new framework or library shouldn't become a reflex.

Although, in the longer term, it is unlikely that these tools and pipelines will remain stable, and the interdependence between them often causes you to have to update one to update the other (especially the more dependencies you're dealing with). I realize that most package managers have a way to deal with this (and via semver/good version practices), but sometimes finding the right stable combination of versions of dependencies is like finding the magic incantation.

It's usually not advisable, but I genuinely think classical CGI is beautiful mechanism for dynamically generated pages. It's a natural extension of Unix scripting: shebang'd scripts in any language, environment variables, stdout. Job's a good'un.

What is good for developers is bad for the industry. How else would they justify creating frameworks in different languages if all people are doing anyway is writing text to (F)CGI stdout? It is much better for the companies/groups involved to make people believe that there is something wrong with this and that they should really be using a "proper" framework.

Who do you think is making money off open source frameworks?

The whole cottage industry of software engineers, authors, and consultants who implement these solutions.

Consultants that wrote those frameworks in first place and offer their services for help, or go to conferences giving talks about them.

Yep, in many cases the frameworks arise from patterns someone solved while working for BigCo, then decided that the pattern they used was cool enough to share with and be useful for others. Open source is hugely thankless and tons of work, but it can be very rewarding in ways you can't buy, including meeting with interesting / awesome people.

Funny aside, it took me many months as a teenager who did not know the ways of *nix to "get" CGI. It was very enlightening to eventually realize that it was so simple that it had eluded my understanding. My mind, coming from messing with Win32 in Visual Basic 5, refused to believe that you just make a program that writes plaintext out to the console, and that text is what gets sent to the browser, and that just works.

If you work on web apps, you absolutely owe it to yourself to understand HTTP and CGI. The one page I'd recommend to quickly grok CGI is http://www.oreilly.com/openbook/cgi/ch01_04.html . Also learn how to use cURL and understand everything that is happening inside the Network tab of Chrome or Firefox dev tools (they're very similar these days). Set up MITMProxy between your proxy server and your apache2/nginx, put it into reverse proxy mode and point the proxy at it, then it at httpd, and understand what you're seeing.

I don't have a good link for HTTP but I promise it'll help a ton with debugging things and generally having a sense of what's going on at every level.

I definitely agree with you. And we are better off compared to the hack-hell it was when you were doing [0] (yes, that is still the tutorial), but I feel we are still finding our ways very much. If the progression from the old 'install and start developing and deploying' to the current brittleness and dependency hell is going to continue into the future, I will find something else to do :)

[0] http://php.net/manual/en/tutorial.firstpage.php

To quote DevOps Borat: "Cloud is not ready for enterprise if is not integrate with single server running Active Directory."

And with service accounts, API tokens, client certs, partner management of users, etc with OAuth and micro services, I really wish we just used LDAP for everything.

I try to evaluate many new "hot" frameworks using the LDAP test as well. For non-enterprise usage, I use the file upload test.

Specifically, is there a simple example showing LDAP integration (or file upload/catcher). If not even that is documented and there is no example, the framework is likely not ready for usage. Seriously, why go thru all the hassle of starting a framework and not even cover basic use cases?

https://github.com/turbolinks/turbolinks

The latest version is "supported only by" rails. (I mean that you should implement the server side part in your language/framework)

(in php/asp.net/python you should write something in backend for serve javascript responses as is it in rails with files .js.erb)

"When you follow a link, Turbolinks automatically fetches the page, swaps in its <body>, and merges its <head>, all without incurring the cost of a full page load."

Is the cost really that high to warrant this?

It prevents the browser from requesting all the external files (CSS and/or JS), so yes, it may be that high.

I would have assumed they would be cached?