I'm not sure where you get that idea that boring technology is a minority opinion. Your conservative approach favoring mature technology is a sentiment expressed by the majority and brought up repeatedly on HN as a highly upvoted point of pride. Examples:
577 points: Choose Boring Technology : https://news.ycombinator.com/item?id=9291215
553 points: Happiness is a Boring Stack : https://news.ycombinator.com/item?id=12788804
I have seen zero articles upvoted to the front page that make a case for using the latest whizbang tech stack for an "unscientific best reasons". (E.g. Rust is new ... but the front page articles on it are usually tutorials, proof-of-concept comparisons to C++, or something about DropBox using it in limited spots where Golang's memory footprint was unacceptable. I haven't seen any frontpage article proselytizing its use as a tech strategy to help a startup succeed or scale out.)
If this wasn't a phenomena then the posts you linked seem kinda pointless.
That may actually happen but it's not relevant to my point.
I'm pointing out that exabrial presented his opinion about choosing "uncool" tech as if he was a lone voice crying out in the wilderness. He's not a lone voice.
Even though exabrial ran into a project apparently enamored by shiny new toys, that doesn't take away from the fact that the overwhelming popular opinion is to just use the older stuff.
For example, every time a thread about "Javascript fatigue" comes up, the HN commenters pile on complaining about the speed of change in the ecosystem and the flavor-of-the-week framework. No thread about new tech ever has "I'm going to use this brand new week-old framework in production!" as the top voted comment -- nor is there ever an article recommending such a strategy upvoted to the front page.
>If this wasn't a phenomena then the posts you linked seem kinda pointless.
They're not pointless but they may have been triggered by a sample size of one (Dan M. writing about regrets at Etsy) or zero projects (Jason Kester writing about what he hypothetically would do). Both those blog posts can be written for audience contemplation ... but ... simultaneously not an indicator about most of us being restless programmers trying to deploy shiny toys into production.
Based on those 2 blog posts (and many others like them), and the followup comments in HN threads overwhelmingly expressing the same conservatism, I'd say exabrial doesn't realize the majority actually agree with him.
* "18..." -> JS Libraries?
* "certain version..." -> TypeScript / Babel?
* "another to run" -> CommonJS / SystemJS?
* "stylesheets were written" -> SASS / SCSS?
Bleeding edge syndrome is definitely a problem in technology but the opposite can be too. Not leveraging technologies that increase productivity and performance can be just as impactful. I'm not implying that you're doing that.
https://medium.com/@wob/the-sad-state-of-web-development-160...
Had to laugh at that!
In the recent Westworld episode (S01E05), the lab tech was trying to program the bird's AI and his file was called "New Script.wws", where .wws is apparently "west world script".
Look here: http://i.imgur.com/oG9xM8o.png
Immediately, the thought crossed my mind, "Must be fucking JavaScript! No wonder the AI will soon start killing the humans" :-)
In my faux outrage, I went into theoretical scenarios of how exactly JS caused SkyNet. To be fair, once my flash of righteousness passed, I took a closer look and .wws looks nothing like JS. Also, there seems to be C or C++ on the LHS.
I still bet WWS is some kind of duck-typed shite that relies on the cult of TDD to keep the robots' behaviour safe.
checkNoKillMode(str). "Look, all my tests pass. We have 100% coverage".
Yeah, except when str == '', in which case it evals to false. Of course, there's no test case for that.
My theory is that there are many front-end designers that only know html, javascript, and css, and suggested javascript on the back-end, because they don't know any other language.
I've been a part of many of the javascript framework communities like Ember.js over the years and it's filled with designers, not developers.
But it also depends on your optimizations. If you are a small company, you want to focus on having a small footprint because server space costs more to you.
Large companies don't care about server space costs, because it's negligible compared to the cost of a developer salary and benefits. So, they would rather use a large and bloated framework that helps with productivity because less lines of code need to be written.
I've worked at a few large corporations that didn't get that much traffic. They all used enterprisey, inefficient, and bloated frameworks. Nobody really noticed because they could just throw some more hardware at it and the traffic to the site was fairly low.
> checkNoKillMode(str). "Look, all my tests pass. We have 100% coverage".
> Yeah, except when str == '', in which case it evals to false. Of course, there's no test case for that.
So much this.
I think this is a result of all of the tooling and automated building that's "necessary" to cludge everything together.
ES6 features and TypeScript are great, for many reasons, but they don't work immediately in the browser. You need precompiling and something like CommonJS or SystemJS to handle importing libraries not defined in HTML. SASS/SCSS really improves stylesheets, tremendously improves them, but you need to...precompile. Finally, JS heavy apps turn into a hodgepodge of JS, CSS, and HTML that just doesn't really...sit well, so most people will use tooling to establish some sense of ordering.
That last step is both a boon and a curse. Automating the process makes development very easy and saves a lot of time. That tooling is also inherently complicated to an outsider and is a large, ugly barrier to entry.
One of the major problem front end development seems hacky is the browser quirks and developer's wish to get more out of browsers for which they were not designed for.
What's funny to me is that I've had a track record of leading and building core parts of successful applications used by millions of people. Yet, when I go to interviews, often they don't seem to care about my successes. And, to them, my methods look ancient. And, they express disbelief when I ask for $200k (a paltry sum compared to how much time and money that they'll spend).
I don't think he was talking about technical details, he was merely trying to emphasis on the importance of ignoring trivial things that might not mean (at an early stage esp.,) as much as one might think... And I'd agree..
At an early stage one should have google like garage office and just stay focused... focused.
twitter isn't facing problems due to less revenue.. but due to abundance of the expenses.... just gave a very broad example to make the point.
Or they are using $(Obscure new Functional Programming thing) which makes Haskell look like VB in ease of use and only two people on the team know how to use it (kind of)
Or using (invented here thing that could be replaced by regular DB/other existing system) but since it was one of the founders that did it nobody is allowed to touch it or fix bugs
Needless to say, I wrote zero lines of code during those two weeks, and the company shut down shortly after that.
At the very least they needed to hire a Haskell dev, not a JS dev, even if the language itself was JS.
The rule of thumb is if someone is using a more complicated stack than me then they're foolishly overengineering their app and if they're using a simpler stack than me then they're unsophisticated novices.
Let's say that I'm a startup CEO and don't have a lot of money, but want to hire great engineers. I'm competing with giants with a lot of money, so I'm trying to offer everything I can - and all I really have is creative freedom. And if engineers choose to use it to learn new frameworks and in general, get a little crazy, it's fine by me, as long as it keeps them happy and not looking for greener pastures.
These types of developers are always looking for greener pastures. No fault of their own. They should be. If all you "really have is creative freedom" you can't compete with the bigger guys who provide that + higher pay + equity + perks.
It would be better to choose a tech stack that is best for your company and attract talent that actually wants to work on what your startup is doing vs playing with the latest shiny thing.
You could offer them money, or equity, or perks, but the kinds of people you really want would happily take a QoL and pay cut for more stimulating work -- the kind of work that puts them at the forefront of their field -- the kind of work they could write blog posts and give conference lectures about. So you offer them creative freedom, let them pick their own stack, let them use the new trendy framework, let them set up a fancy build and deployment pipeline even though you're a small shop, let them use their favorite language that they never get to use outside of personal projects. Let them solve your boring problems in fancy, clever, maybe a little over-engineered, but fun ways that also make you, the business, look like you're up to date, modern, and ahead of your competition.
I am not at all opposed to using new and shiny. I use new frameworks, etc. in my business often but there is a balance. I generally stick to boring and proven for business crucial stuff (especially back-end) and new/shiny for not so crucial. OR sometimes a new framework is the best decision for the business. In that case, that framework wins.
I guess I feel as a business owner, I have a responsibility to do what is right for the business and our customers. If a developer doesn't want to work on what is right for the business or our customers, I don't want that developer.
People just adding cool toys not because they need it but because it is "cool" or "new".
Why do we need to "compile" our JS which just adds to our development time and then we have to dedicate time to debugging these when they break.
I like ES6 but sometimes I question whether it is worth the trouble.
Sure, some people only want to work with new things because they are novel. That's human nature.
However, that's not all of it. Many people strive for new tools not simply because they are new, but because they are better in some way. Of course, I understand that some people over-estimate how much better the "new" technology is, in practice. Transitions take time.
A side note: most "new" things are often based on combinations of "old" things. One of the big problems with some "new" tools isn't simply that they are "new" -- it has to do with their maturity. Applied person-hours, working on representative problems, helps shake out problems or edge cases with various technologies.
Take Clojure, for example. I reject the notion that calling it "new" or "old" is particularly useful. When it was released, it was based on many iterations of Lisp and the JVM. Clojure has been very stable.
Some people underestimate the importance of tooling and the ecosystem. Or they may underestimate integration; e.g. in the case of a new language, does it have a solid C or Java native interface?
Also that for the 10 other 'not any extra trouble' things
Until of course something breaks. Or is not giving you the result you wanted.
Or you need to urgently again and one of the hundred requires you need got a new bug or npm is out.
Then you need to debugger your code, compiled code, sourcemap files, compiler, compiler options, the layer and layers of configuration JSON scripts and mobile browser.
Yes, transpiling es6 -> es5 is adding another layer of complexity to your codebase, another thing that could potentially go wrong, but the reality is that the development gains we get from being able to use es6 are far more important than a small chance of a problem. It works well enough that you don't even think about it after leaving webpack in watch mode.
Especially since ES6 is being converted to ES5 at the end of the day.
es6 has become pretty well supported by modern browsers, so maybe after a year or so, we'll just be calling it "javascript" and running it without babel. I expect everyone to continue to transpile, though, to get newer features as they come, as the plan for ES is to release new language updates on a yearly basis.
My team has been using it for most of this year now and we've had no problems so far.
This seems like you're deliberately trying to make things sound way more complicated than they actually are. If there is a bug in the code on a certain platform, you examine the bug on that platform and add the appropriate feature detection code to fix it. There is no need to debug the compiler and every other tool in your stack, it all compiles to javascript at the end of the day and assuming you're not running a minifier in development, 99% of platform specific bugs are readily apparent and almost certainly the developer's fault (i.e. not the tool's fault)
After with, do your team do automated regressive tests the oauth support and all other functionalities on all the regular browsers and mobile browsers?
+ Older version browsers?
+ Older browsers in older version of Linux, Mac, Windows?
+ Browsers with plugins such umatix, unblock origin, noscript that blocks scripts from your own domains + other domains?
But If they are doing things that are destroying value then are they so great? Or maybe they are great but not a good fit for you. I.e. they need a Google not a Crud Inc.
You might have been able to turn things around for the company with your experienced view.
You can tell a startup is focusing on the wrong thing when: They're using the 'newest', most obscure, programming language or frameworks available because it's the 'best' for some unscientific reason.
Instantly I hear the argument "Yah, but if we need to scale, we don't want to re-write." Ok, you're going to rewrite anyway. Right now your problem is producing quality code that additional people can onboard themselves with. Chances are you can produce something very practical using plain GET/POST operations and gradually add more interactivity on the client side if you prove your product out.
The stem of my rant is this: Recently I was thinking about picking up some side work for extra $. The company I was interviewing with described their front end team as struggling to keep pace and needed some temporary help. The product is under NDA, so let's just say it's a shared calendar. Their stack was insane: 18 different javascript frameworks, required a certain version of Node.js to "compile" to ES6, then another to run it in your browser, and the stylesheets were written in some other obscure language. In the second interview, I told the product manager I think he's been had: the reason your front end team is struggling is because they're not being practical, they're busy with shiny toys. He said he had a feeling, but given his situation he didn't have much of a choice but to continue. He thanked me for being honest and said he understood if I wasn't interested anymore.
Anyway, there's a lot of really "cool" stuff to get distracted by as developers. I think a lot of us need to sober up and really meditate on the phrase "do the simplest thing that could possibly work".