I'm Joining LinkedIn - <AUTHOR> http://tomdale.net/2017/01/im-joining-linkedin/ <comment><USER3> > Perhaps you can write a tiny web app that loads instantly and still retains > a full set of features, but most of the world cannot.

I've long been skeptical of this line of thinking emanating from major thick client JS framework authors. I think they underestimate what people are capable of.

> Over time, Ember will become like gcc -O3 for web apps, intelligently > optimizing them and delivering them as fast as possible, piece by piece, to > your user's browser.

I've been observing these trends for years and what I'm seeing is this: ever since these new thick client JS frameworks became so trendy, web performance has dramatically _decreased_ , not increased.

This one-two combo punch of framework authors condescending their users as "our target audience is devs who can't hand code" while simultaneously promising performance that's just as good as hand coding and perpetually failing to deliver is a toxic stew that is crippling web performance.

<comment><USER4> As software developers I think its easy for us to jump on this bandwagon that if you hand code all the things then you can make a super fast site and the internet would be such a wonderful place; and then thinking its all those heathen script kiddies using these junk JS frameworks slowing our browsers down.

I know I'm guilty of this line of thinking so I'm not judging, but I also think many companies big and small are actually making rather rational decisions when it comes to site performance and the use of JS frameworks. For instance where I work its common for us to knowingly slow down performance on a given page because the feature makes the company X money that offsets the performance loss and the time and money it would take to make it perform better. This compounds over time, but all along the way the business is making reasonable decisions. Frameworks like Ember allow great developers to add powerful features quickly for the businesses to monetize on. I don't think we should write off performance initiatives in these frameworks just because we know they won't live up to a vanilla JS implementation. I also don't think its fair to disparage the movement of thick JS frameworks on these grounds. Many of start-up's and large companies wouldn't be able to lift off products as quickly as they have without the head starts that frameworks such as Ember have given them.

<comment><USER3> The bandwagoning is disproportionately on the side of those leaning towards big frameworks. Look, I've been on the inside of large companies making framework choices and rarely is the decision rational. Often it's based on what's popular and based on the assumption that popular things are popular for good reasons. Biased metrics get thrown around to justify preconceived notions, and off to the races we go. Years later, everyone sees the old stack as "old and outdated" and a strong desire to throw it all away and rewrite it with the new hotness takes hold. Then the entire irrational process repeats itself.

I'm not saying the big trendy thick client JS frameworks are the wrong tool for every job. But in my experience they do seem to be the wrong tool for an alarming number of jobs they are presently being used for. And I'm not just spitting rhetoric here. I'm more than happy to put my money where my mouth is. If you want to know specifically when I think a big thick client JS framework might be the right tool for the job and when it probably isn't, this article does a good job of outlining that: [https://www.sitepoint.com/javascript- dependency-backlash-myt...](https://www.sitepoint.com/javascript-dependency- backlash-myth-busting-progressive-enhancement/)

As for the tradeoff associated with developer productivity vs. performance, there is some validity to that. However, I think people overestimate the developer productivity gains the frameworks offer. You only get productivity gains if your whole team is already fully trained on the framework. And in addition to the performance tradeoffs, you also risk your codebase having a shorter lifespan because the framework may make breaking changes to its API some day (e.g. Angular 1 -> Angular 2), whereas a vanilla JS implementation that relies on smaller, single purpose JS libraries will age considerably better.

<comment><USER5> Large companies almost by definition need to hire a lot of developers. Seems to me that it would be an absolutely rational and sensible choice to use popular frameworks keeping those constraints in mind.

Google would go bankrupt from a combination of the insane salaries they'd have to pay and the inability to ever fill jobs if its entire stack was based on Haskell.

<comment> Ar-Curunir Probably not; people would just learn Haskell.

<comment><USER6> And that would be so amazingly beautiful.

</comment></comment></comment></comment></comment></comment><comment><USER7> The ember roll out within LinkedIn has been a disaster from those I know still working there.

No one likes it and it takes over 20 minutes to "build" the code from scratch.

We're talking about frontend code, mind you.

At a certain level in LinkedIn, someone decided to standardize on Ember. Fine. But there were many issues, and instead of finding a more suitable and workable pragmatic framework, LinkedIn is instead deciding to hire Ember people to fix up their framework so it's actually useable. We really do work in the only industry where you can get hired to fix a mess you created yourself.

Anyway, besides the recruiter app, is LinkedIn really worthy of a SPA experience? Last time I checked isn't most of the traffic a quick "accept connection" or reply to inmail, or maybe check who viewed your profile bounce? Does the average user actually spend time in it? Probably not.

I'm reminded by a certain quote from a friend: "At a certain level in McDonald's, the managers start thinking of themselves as restaurateurs, and not fast food servants."

<comment><USER8> I can't imagine where that 20 minutes number came from. Maybe a fresh `git clone && npm install && bower install && ember start`... But even then that seems very high (and somewhat irrelevant since subsequent builds will take seconds). Citation needed?

The people who are talking publicly seem very excited about how things are going. Chris Thoburn (runspired) was on Ember Weekend a few weeks ago talking about the work he's doing on Ember Data over at LinkedIn.

<comment><USER9> if you count all the jenkins task with automated unit tests and integration tests, etc. this is pretty believable. It happens all the time.

</comment></comment></comment><comment><USER10> Does this mean I can expect improvements in the mobile web app? It has so many issues that I won't click the links on my phone.

No, I don't want the android app. Stop asking me.

Stop directing me to my home page when I clicked a link to go deep into the site.

And please stop showing that spinner for unlimited time.

Also, these may be back end issues but both the desktop and mobile web sites fail to update the notification indicators after you've responded to friend requests or read your feed.

<comment><USER11> Oh, you're preaching to the choir. They're the worst. By far, the worst mobile experience, and by far the most aggressive push for their mobile app. I choose not to open their mail on my mobile phone. And obviously I don't want their mobile app.

They must think of themselves as Facebook Messenger, which most people check with obsession, or at least aspire to become that.

<comment><USER12> What's the reason for this?

Is it because an app-user is a much richer data slave?

Airbnb are also relentless for pushing users to their app even though the app is an inferior product to their website.

<comment><USER13> Exactly that. The tripadvisor experience is also bad, they block all but 5 reviews from their mobile site to push users to their app

</comment></comment></comment></comment><comment><USER14> Lots of flagged comments, I suppose because of short quips related to the sleazy things LinkedIn has done in the past.

I'm sure he's not unaware of those things. I wonder if he's thinking he may be able to influence them? Discourage dark patterns? Discourage the current mobile experience that's broken unless you download the app and/or log in?

<comment><USER15> LinkedIn's behavior is driven by profit. They want advertising money and are willing to sacrifice their users for that, just like Google, Facebook and more recently Microsoft, which happens to own LinkedIn.

This person probably just wants to work on interesting things (for them) and get paid well, just like the thousands of employees at the other companies I mentioned. Fighting for ethical software doesn't pay. Nor does it make one particularly popular.

<comment><USER14> I think there is a line where it makes sense to speak up. Short term revenue isn't always worth the long term reputation hit.

<comment><USER16> > Short term revenue isn't always worth the long term reputation hit.

What? 200k/year is a lot of money and a norm in these companies. With 10 years of such money, I can retire for life.

</comment></comment></comment></comment><comment><USER17> Regardless of web tech, Tom is an awesome dude and Linkedin is lucky to have him. ^5

<comment><USER18> I kind of agree with this. Saw him give a presentation a few years ago, and was very impressed (and entertained). Tried out ember after that, and quickly found some dead ends for my use case, but hey- at least he actually got out of bed and made something.

Another thing to bear in mind is that ember is more or less an independent technology, whereas Angular and React have the weight of giant corporations behind them.

</comment></comment><comment><USER19> Some of the discussions on this thread remind me why I'm pleased I don't work on code for browsers.

I've been writing native (or python) stuff for a long while, and I've come to rely on the assumptions the code makes being roughly constant (from the point of view of the language definition.)

My brain recoils at the idea of targeting a large number of different systems at once, like browsers and their versions, and then have the same code run on the huge set of future versions...

If your code behaves differently under a new GCC, it indicates a bug in your code. If your javascript behaves differently in the latest Chrome, that's just life.

</comment><comment><USER20> > Joining LinkedIn

Great, I'm glad Ember is gaining more traction in enterprise... but what does this mean for things like Fastboot, Ember 3.0, glimmer 2.0, ember-cli 3.0, and the whole cast of in-room-elephants such as ember-redux, flexi, ember-data, vr, etc.?

<comment><USER21> The mobile-web version of LinkedIn and the new website are built in Ember. We already use Glimmer 2.0 because we care about web performance. So we care deeply about many of the things you mentioned.

Source: I'm the lead eng for our consumer group

<comment><USER22> Just out of curiosity I logged into the mobile site. First I was greeted with "your browser is not supported". After I logged in, I found a website full of nonsense news, mixed with advertisements. Not a place I would go to for any meaningful reason.

My personal conclusion: LinkedIn is a lame duck. The previous owners sold it at the right moment to Microsoft.

</comment></comment></comment><comment><USER23> We need specialists too. We need the folks who can tune x86 assembly better than -gcc 03. We need people who can write segfault free C++ code, and we need people to fix the Rust borrow checker bugs [http://blog.ezyang.com/2013/12/two-bugs-in-the-borrow- checke...](http://blog.ezyang.com/2013/12/two-bugs-in-the-borrow-checker- every-rust-developer-should-know-about/)

There are plenty of available consumer of good tools, with more coming into the market every day. We need more specialists. Every person has the same capacity, the same brain, the same capability to become an Einstein, a Hoare, a Dijkstra, a whatever modern Comp Sci figure or AI leader you admire these days.

<comment><USER24> > Every person has the same capacity, the same brain, the same capability to > become an Einstein

God, I wish this were true, but it definitely isn't. We're trained to think it is, by virtue of (first) our belief in meritocracy (it's value, and that we're in one), and (second) by RPGs and other games.

Our baseline cultural assumption is that things are, in the end, fairly balanced... but this just isn't the case.

I _think_ it's demonstrable via the existing of evolution: There have to be differences between individuals on an inheritable level in order for evolution to occur, and if there are such differences, the playing field is NOT even.

<comment><USER25> > ... and (second) by RPGs and other games.

I was expecting our western values rooted in the belief that all men are created equal or something.

I really don't think RPGs and other games have somehow conditioned us (the niche market that even plays them) to think we're capable of anything, but I quit WoW a long time ago.

<comment><USER24> I really think they have. RPGs may be niche, but games aren't, and there's an expectation of balance between player positions in games; even across the equipment load-outs. There's expectations that you trade, say, fire power for precision; resilience for mobility; and that the trade is equitable.

</comment></comment></comment></comment><comment><USER26> > artisanal, shade-grown code doesn't scale to large engineering organizations

Some leeway could me made around that statement. People who work in fishing and agricultural industries for example could benefit from unique and specially crafted services when it comes to job search and fulfillment. There is a certain effectiveness in the one-size-fits-all approach of applications like Facebook but it could stand to exist within a more diverse ecosystem.

<comment><USER27> > Some leeway could me made around that statement.

What do you mean? Who needs the leeway?

(I suspect "artisanal, shade-grown code" just means "bad", but perhaps stated in a more PR-friendly way.)

> People who work in fishing and agricultural[...]

What are you talking about?

I've known several people who work in fishing (fish farming, specifically), and I can assure you that they weren't particularly concerned about "job search" or "fulfillment". They _were_ concerned about maximizing profit amidst the intense competition.

Can you relate what _your_ fish-worker acquaintances/friends told you?

<comment><USER28> I thought "artisanal, shade-grown code" was such a delightful phrase. I took it to mean not bad, but rather too costly for practical/mass use. Like some people can afford to buy $6 lattes, and those are likely very tasty lattes, but Folgers is going to move more beans.

<comment><USER27> It's an amazing phrase. AFAICT it doesn't actually mean anything. I certainly _understand_ why such a high-profile developer would choose such a "bland, yet poetic" phrasing; my issue is just with trying to interpret it as somehow insightful.

<comment><USER29> it pretty clearly meant "code that has been lovingly handcrafted to the specifications of the problem", as opposed to "churned out using a mass- production framework". the analogy works for me.

</comment></comment></comment></comment></comment><comment><USER30> Is this concerning? [https://www.google.com/trends/explore?q=ember.js,react.js](https://www.google.com/trends/explore?q=ember.js,react.js)

In any case congrats on the new gig Tom.

<comment><USER31> I've moved from Ember to React year back. Then over year I've (crappily) recreated Ember.js using React.js and libraries.

Ember.js had many strong parts, but also had many issues that pulled it down. Documentation overfocused on explaining concepts but not providing examples of how to solve real issues. New release every six weeks bringing painful deprecations and changes. Lack of realworld apps to look up to for examples. Ember-Data that worked out the box... unless you weren't using Rails for your backend, in which case you've needed bridges and drivers for it to work. Rich of resources assuming that your backend is Rails or that you have enough of understaing about it to translate examples for your tech. All of this eventually pushed me away to React.js that seemed less opiniated about your backend and richer in examples and manuals, as well as unopiniated enough to forgive my mistakes and let me lear from them. Since moving I've made a lot of mistakes with my own solution build using React.js and libs from its ecosystem, which eventually made me understand design choices behind Ember.js, but I still preffer to improve on what I have now instead of considering returning to Ember.js.

<comment><USER32> I agree with your points about documentation and release cadence (they do have a LTS release now though), but we've used ember-data with a Django backend since day one and it's been flawless in every respect. Once you configure it there are no issues

</comment></comment></comment><comment><USER33> Who signs off moving huge, billion dollar companies onto immature, "hip" JavaScript frameworks? I don't get it. It's too niche. It's too risky. How are you expected to make hires for specialists in such a niche technology which may or may not be here in a few years?

Do they just hire good JavaScript developers and train them for Ember? And also tell them they may have to retrain in another framework in a couple of years when Ember becomes defunct?

<comment><USER34> Was it too hip, niche, etc to use Spring for a Java project in 2007? Because that's how old Ember is now.

I don't really get why you're talking as if thick client web apps are some sort of unexplored continent that prudent enterprises should stay away from. Like it or lump it, they've been around for a while and there are now enough of them that they will be around for a long while yet. And if you're going to build one of those, _you should use a framework_.

</comment></comment><comment><USER35> This makes a lot of sense - LinkedIn has basically went almost all in (if not all in) on Ember. Being probably the biggest tech company relying so heavily on Ember, it's unsurprising that they want a core maintainer of it on board.

<comment><USER36> Just curious but what happened to Dust? Is it still a thing with them?

<comment><USER37> It is still a thing. (Source: I work there.)

</comment></comment></comment><comment><USER38> It seems to me that the true analogue of gcc -O3 for web apps is the Google Closure Compiler in advanced mode. How effectively can Ember applications take advantage of this?

</comment><comment><USER39> > LinkedIn has bet big on Ember.

I like how as technologists we talk about "betting" on things. As if technology choices are like gambles.

<comment><USER40> Aren't they?

If there are two competing technologies, generally one will dominate, or more likely: both will be replaced by something new. You have to gamble that the technology you pick will stay relevant for long enough to be worth it.

<comment><USER41> But if it works, how is it a gamble?

<comment><USER42> You are choosing an outcome which you think will happen in the future. It is not certain that this outcome will happen.

<comment><USER43> I think a gamble needs to be predominantly a game of chance. Merely having an outcome that isn't certain would cause any choice to be labelled a "gamble", from crossing the road to turning on the kettle.

Instead I believe choosing the right software platform is predominantly a game of skill and experience.

Remember that old canard, "a poor craftsperson blames their tools"; the corollary is that a good craftsperson chooses good tools.

<comment><USER44> Sports betting is one of the most ancient and most popular form of gambling, even while the actual games are, as you say, games of skill and experience.

A good craftsman can rationally choose tool A over tool B, however, for software platforms it _is_ a major gamble whether A v2 will still be preferable to B v2 - it is (a) unknown, not decided by A being "better" than B, and (b) generally outside of your control.

<comment><USER43> In sports betting, the gambler has no control over the parameters or the outcome of the game. Indeed when they do it is considered match fixing and may be illegal.

In software tool/platform/protocol/standards selection, the person making the choice is a direct participant in the game, can control the local (and possibly global) quality of the outcome, and has (or should have) a priori knowledge of the characteristics and context that will shape the future viability of their choice.

Sometimes that requires a really deep dive into technical documentation and/or source code; sometimes it means assessing product origins, or the community/ecosystem around it; sometimes it means looking for warning signs (e.g. patent encumbrance, a toxic vendor, unnecessary interoperability barriers, opaque licensing or pricing); it almost always means understanding the values & norms & preferences of the people who'll be bound by your choice. Usually a combination of all these things and more.

The argument that we can't tell, in advance, doesn't wash with me; it is not borne out by my experience of being either the decision maker or decision victim, and just sounds like an excuse for a bad decision and/or poor execution.

What happens later is people saying "I made a bet and lost", a terrible post- mortem that smacks of denial, and one I've heard all too often. But whenever I've make a wrong call - and I've made plenty over the years - there was always, always, always some factor that I missed. Whenever I've made a decision that turned out really well, it has always been on the back of research and analysis and reasoning, possibly (and increasingly with experience) guided by gut feeling. "I made a mistake, what can I learn from it?" is the only hindsight I tolerate for myself and strongly encourage in others, and it is not compatible with framing decision-making as a gamble.

</comment></comment></comment></comment></comment></comment></comment><comment><USER45> Ember is a great framework and equally as powerful and popular like angular or react. yet its developed by just a bunch of guys on their free time unlike other frameworks which had huge enterprise support. I hope tom leverages the linkedin support and take ember to next level.

</comment><comment><USER46> LOL. I love how full of his own crap Tom Dale has become.

Ember is a good framework with a lot of potential, but more than anything it needs a good PM. Ember devs just spent nearly 14 months rewriting the layout engine (Glimmer 2.0) that they had spent the prior 8 months writing (Glimmer). And what do they have to show for it? A 100ms or so speed boost on complex views. Instead they should focus on fixing up the crufty parts of their API and adding feature they've been promising users for years. Instead Tom Dale has been off writing FastBoot, an even more niche component of Ember that very few apps will even use.

React and Angular are far from perfect, but one upside is they have parent companies to help keep them focused.

<comment><USER37> Having worked on Glimmer 2 myself, I don't think it's accurate to say that Ember devs worked on it for 14 months (that is, it took 14 months of work to same 100ms). It had initial work done for a long time and then it sat for a while unchanged because it's an open-source project that people work on when they have time. Month later work started up again to get it out the door.

I think that since LinkedIn is "all in" on Ember it will help to get some of the cruft removed and things moving forward. LinkedIn has probably the largest and most complex Ember app in existence, so there are a lot of learnings to take an use to improve the framework and ecosystem.

<comment><USER46> Well the Glimmer 2.0 effort started around the same time Ember 2.0 shipped (Aug 2015). That was 16 months ago, Glimmer 2.0 shipped about 2 months ago, ergo 14 months. I agree that it wasn't under development the entire time, but it was a blocker for many other features the entire time.

Basically when 2.0 landed, routable components couldn't be worked on until glimmer components were completed. Angle brackets, Improved Pods, etc, same.

So even if it wasn't under dev that whole time, it held back other features that would have really improved Ember.

</comment></comment></comment><comment><USER47> Maybe you can help fix their new search UI. As a power user, I find it basically unusable. For me, that was the final nail in the proverbial coffin of usability. It is so bad AND slow.

</comment><comment><USER48> Interesting they made that bet on Ember... My only assumption is they made that bet a few years ago and have been working on the refresh that just went live. Seasoned Ember developers are going to be hard to come by not that they couldn't settle for any other JavaScript specialist. I'm debating on an Ember gig this very moment and am slightly bothered by the idea of spending a year on a framework that is on a downward popularity trend...

<comment><USER49> > downward popularity trend

Ember has always dwarfed by Angular and now more recently.. React. They simply have more marketing dollars behind them. That said, it has always had a strong community behind it, and believe it or not it's still growing strong.

<comment><USER50> Marketing dollars?

<comment><USER51> Meaning: Ember doesn't have a big company actively spending money on marketing, like Angular - Google and React - Facebook.

</comment></comment></comment></comment><comment> javascript-this As long as companies continue to value maintainability over efficiency you're going to have slow sites.

</comment><comment><USER52> First I thought this was Jim Dale - the amazing narrator of Harry Potter - <USER2> was pretty confused.

</comment><comment><USER53> So Tom Dale is one of the creators of Ember. Now he is joining LinkedIn to work with Ember. I think this is a little sad. I can't stop imagining that he thinks that something like React is better than Ember in all situations, but since he has such high Ember credentials and somehow LinkedIn decided to go with Ember then he feels he must accept that job.

<comment><USER54> Huh? Why would you think that?

<comment><USER55> I think here we have the "my tooling/programming language is the best, in every situation everytime".

I could be wrong. Edit: typos

<comment><USER56> Yeah, but fiatjaf is saying that Tom Dale (one of the creators of Ember.js) believes that React is better than Ember in every scenario, not the opposite. That's the part that doesn't make sense.

<comment><USER55> I think it's about he thinks that Dale believes. And thats based on the opinion that React is the best in everything that Ember could do..

If Dale Said it otherwise, im sorry. Its all about opinions Here :-/

<comment><USER56> Yeah, but the point is that he's conjecturing and doesn't provide any source. If anything, I'd imagine Tom Dale believes that Ember is better than React in some, if not all, ways given that he's... one of the co-founders.

fiatjaf is literally saying[0]:

> React cane out after Ember, and conquered the hearts of many many JS > developers. Why couldn't Tom Dale be one of them?

And it's fine to wonder that, but he states it in the original comment as if it's a definite thing without providing a source.

[0]: [https://news.ycombinator.com/item?id=13325643](https://news.ycombinator.com/item?id=13325643)</comment></comment></comment></comment></comment></comment>


Show HN: Incrediibli simple shared lists - <AUTHOR> http://diib.li <comment><AUTHOR> Yes it is basic and simple and everything... but it proved to be really nice to get some stuff planning, where you can chip in ideas as a group.

It is shared and is updating on the spot!

<comment><USER2> You can even have lists of lists -- that's powerful!

</comment></comment><comment><USER3> Is there a public source code repository?

<comment><AUTHOR> No, it is anyway easy to code. It is more about the UX and model of exchange ...

We might look into open sourcing if more interest is voiced.</comment></comment>


Ask HN: Is anyone else just tired of JavaScript? - <AUTHOR> I don't see what problems it solves.  Rather, the "problems" that is solves are not really problems to me.  I want to develop software in a stack that is entirely free of Javascript.  Does anyone else ever feel this way? <comment><USER2> I don't care about JavaScript, but I love browsers as platforms; and as long as JavaScript is the de-facto language of the browsers, it will remain an important language.

<comment><USER3> My browser has essentially become my OS (ignoring gaming) Hell, I could even accomplish 95% of my software dev job fully within a browser with online IDEs like Cloud9.

</comment></comment><comment><USER4> I'm actually more excited than I have ever been in the JS ecosystem. Sure, there's framework fatigue, but ES6+ features have been a pleasure to learn and use, and picking up Typescript has been a serious boon to a more OO style approach to client side engineering. The previous two years have been refreshing.

</comment><comment><USER5> Tired of JavaScript? Not particularly. Tired of the #hype around JavaScript and more specifically the constant frameworks of the week? Absolutely.

I don't think this is a problem unique to JavaScript, however. We see the same sort of thing around technologies. Right now it's ML and Blockchain, earlier it was Cloud and IOT. The industry in general appears to be mostly built on inventing problems that can be solved by the tech, framework, etc. rather than leveraging technology to solve an existing problem.

This may be part of why you're having a hard time finding the problems JavaScript may solve for you. Personally, I find it much easier to follow the "Just In Time Learning" model [https://blog.codinghorror.com/keeping-up-and- just-in-time-le...](https://blog.codinghorror.com/keeping-up-and-just-in-time- learning/). Find out what parts you need in order to solve your problems, learn how they work, and leave the rest until you need it.

<comment><USER6> And I am tired of the "tired of JavaScript hype and new frameworks every week" speech.

It has a huge community, of course there will be new things created every week.

But, if it as bad you will not even hear about it, if you hear it is probably good or better on some aspects compared to others, who doesn't want that? do everyone wanted to be stuck with MooTools or JQuery forever?

<comment><USER7> The major problem is that when you learn something in this current crazy JS/Front world, your knowledge is deprecated 6 months later. I know a developer should always stay up to date with technology by constantly learning, but if I compare what I learned 5 years ago in Python, I would say 95% is still relevant today. But if I look at the JS "state-of-the-art" stack today, compared to the 2 years old, it's completely different. It's very frustrating to invest time and effort to learn something and then hear recruiters tell you things like: "Hmmm no one uses that anymore".

<comment><USER6> Maybe because there is no need to evolve there?

I mean, you can see clearly why we came from jQuery, to AngularJs, then Angular/React/Vue, there was a need.

<comment><USER7> This constant need to evolve is the exact definition of immaturity, for HTML/CSS/JS front-end.

I'm not a mobile dev, but I'm pretty sure when you make the front-end in an iOS app, you don't need to learn 3 languages + 2 frameworks + tooling to transpile + type checker + webpack...

Web front-end is completely broken because the foundation (HTML/JS/CSS) is not the right tool for the need.

<comment><USER6> Now that is a real problem, and it will not be fixed soon.

It is easy to a single company define how they want their platform to be, like iOS, but browsers are a different beast, as every change need to be agreed between several major companies.

</comment></comment></comment></comment></comment></comment><comment><USER8> JavaScript itself isn't the problem. The ecosystem is the problem. There is so much bad stuff out there that I stop reading articles about hot new software when they mention npm.

</comment><comment><USER9> This is really vague. Javascript is necessary for building rich web applications. What are the uninteresting problems you see as Javascript's main purpose?

</comment><comment><USER10> _> I don't see what problems it solves. Rather, the "problems" that is solves are not really problems to me._

Then why do you use it?

</comment><comment><USER11> It solves the problem of "browsers need some form of embedded programming language". From there, it makes some degree of sense to also use it in the backend, to avoid multiple programming languages in the same codebase.

On the other hand, I've never written anything in Javascript. Maybe I'd have a lower opinion of it if my stack made heavy use of it.

</comment><comment><USER12> > I don't see what problems it solves.

It solves the problem of forcing a medium that was originally intended for documents and presenting information(the www) to support rich, interactive applications.

The whole html/css/js thing is a giant, ugly kludge, but it's what we're stuck with.

</comment><comment><USER13> I believe that's why Web Assembly ([https://webassembly.org/](https://webassembly.org/)) has been created. Eventually we will be able to use any language that can compile to Wasm.

<comment><USER14> Right now we can use any language which can be compiled to JavaScript. What will change? Wasm is not faster than JS.

<comment><USER15> For one thing, web assembly's architecture more closely matches the traditional backends that language designers are familiar with. Compiling to code to a byte code is a pretty much solved problem, and we have compilers that do this. Finally, while web assembly may not be faster than JS (although that really remains to be seen), it is faster to load.

<comment><USER14> AFAIK, today compilers are producing both asm.js code and Webasm binary. Webasm is for tomorrow, asm.js is for actual use, because it's backward compatible with any JS enabled browser.

Webasm is not so compatible. I tried to run random demo and got error message: CompileError: wasm validation error: at offset 8: binary version 0xd does not match expected version 0x1. WTF?

I tested [https://webassembly.org/demo/Tanks/](https://webassembly.org/demo/Tanks/) demo, and on my system (Firefox, Fedora Linux 26), asm.js version is a bit faster to load than Webasm version. (Turn off support for Webasm in about:config to test). Asm.js: 1.57s to load from cache, Wasm: 1.82s to load from cache.

So what will happen when webasm finally more closely match traditional backends?

</comment></comment></comment></comment><comment><USER16> My problem is not as much with the language but with the entire platform, I would like the DOM to evolve too, so far only the language was updated.

As a small example I would like to have a built-in dropdown/select that I can css it to my needs then to create my own using nested divs or use one made by others that may have corner cases or is not efficient.

I would also like some standard ways to show a modal, basically more standard APIs to be added to address the most needed things.

</comment><comment><USER17> I'm tired of all the webpack crap, the endless battle of trying to match all its required plugins versions, 10000gb of node_modules and so on...

</comment><comment><USER18> I feel the same way(js is fine for tying together a wbepage however).

I am now rewriting a startup's entire platform from PHP to js for no good reason. They claim they can't find any decent PHP developers and that js developers are easier to come by, yet here I am a PHP developer that has never wrote js outside the browser doing their js work?? Makes no sense.

<comment><USER6> I cant find any aspect of PHP being better than JavaScript

</comment></comment><comment><USER19> To be fair, the language is in better shape today than it has ever been. The ecosystem, that is another matter.

Personally I'd love to completely ditch JavaScript. I'm eagerly following the progress of WebAssembly. I'm certain in 5 to 10 years the majority of front end dev will not be done in JavaScript.

</comment><comment><USER20> JavaScript allows you to develop better UX for the user. Allowing for near- instantaneous feedback to the user.

</comment><comment><USER21> No. Quite awake actually. JavaScript opens up a world of possibilities you cannot do with just HTML. It's the current platform of the browser app. If you are happy with static websites, that's great. Most people are not.

<comment><USER15> I mean... you could replace javascript with any other programming language and achieve the same thing. The choice of javascript as the language with which to access the standardized APIs is arbitrary. Browsers could have equivalently chosen any other sufficiently similar language, like Lua or Python.

<comment><USER6> If it wasn't because of Java the browsers language would be Scheme

<comment><USER15> > the browsers language would be Scheme

And the world would be 10000 times better off for it.

<comment><USER6> wounder if people would still complain

<comment><USER21> Of course they would. About the same things, in the same way.

</comment></comment></comment></comment></comment></comment><comment><USER22> Sometimes, but then I do some work in Java/.NET and part of me wishes I was using express/rails/django or something else lightweight. The grass is always greener

</comment><comment><USER23> Yes. I'm tired of people getting so excited about using such a sub-par language in X environment.

</comment><comment><USER6> Ignoring the browser side, show me a language that can do what nodejs can, as good as it can

</comment><comment><USER24> not tired about JS, but in some cases I don't like that we keep reinventing libraries (for whatever reason), instead of contributing to existing ones to make them better.

</comment><comment><USER25> ES7 and ES8 along with typescript are keeping things fresh IMO

</comment><comment><USER26> Yes.

I am maintaining an Anglaur app just now. What a waste of effort. Everything would have been so much simpler if it was kept server side. Instead we have a ton of duplicated logic.

<comment><USER27> Stating the obvious, but that's the fault of whoever decided to do it in Angular and didn't understand the trade-offs of single page apps. If an app can be just as easily (or more easily) implemented server-side with no 'relevant' impact on UX, it probably should be.

<comment><USER26> It does give a bit more interactivity, but had it been up to me the majority of the logic would be server side with a bit of client side JavaScript. The amount of duplicated code for a very small amount of extra interactivity really doesn't seem worth the effort to me.

</comment></comment></comment><comment><USER28> No

</comment><comment><USER29> I once had to implement excel-equivalent UI functionality (resizable columns, etc) - using javascript - which needed to be compatible on both Netscape and Internet Explorer. Early 2000s, before jQuery or even prototype.js.

Which is another way of saying, don't talk to me about being tired of javascript...</comment>


IBM Bet Billions That Watson Could Improve Cancer Treatment. It Hasn't Worked - <AUTHOR> https://www.wsj.com/articles/ibm-bet-billions-that-watson-could-improve-cancer-treatment-it-hasnt-worked-1533961147 <comment><AUTHOR> IBM have responded: [https://www.ibm.com/blogs/watson-health/setting-the- record-s...](https://www.ibm.com/blogs/watson-health/setting-the-record- straight/)

</comment><comment><AUTHOR> Paywall bypass: [http://archive.is/yoK65](http://archive.is/yoK65)</comment>


Anti-gravity hanging tower defence game: Javascript + Box2D - <AUTHOR> https://webdesignporto.com/

<comment><AUTHOR> Mini tutorial as this is alpha version: \- buildings must hang in order to not be touched by puppets (enemies) \- click on building to upgrade</comment>


CheerpJ Applet Viewer – Runs Java applets without a local Java installation - <AUTHOR> https://chrome.google.com/webstore/detail/cheerpj-applet-runner-bet/bbmolahhldcbngedljfadjlognfaaein <comment><USER2> The only, and still unmatched, advantage of using applets was having access to external devices, such as smart card readers, in order to be used with eID, for example. This is not possible with this plugin. The only interest would be for some old applets you don't have sources anymore and aren't techie enough to use a decompiler to retrieve some codebase to work with.

<comment><USER3> Web USB: [https://developers.google.com/web/updates/2016/03/access- usb...](https://developers.google.com/web/updates/2016/03/access-usb-devices- on-the-web) WebB

Web Bluetooth: [https://developers.google.com/web/updates/2015/07/interact-w...](https://developers.google.com/web/updates/2015/07/interact- with-ble-devices-on-the-web)

and Web NFC: [https://w3c.github.io/web-nfc/](https://w3c.github.io/web-nfc/)

should start making a dent in hardware access.

<comment><USER4> In 10 more years we'll almost be where applets where 10 years ago!

Except now in a slower single threaded language with a worse GUI toolkit.

<comment> yoz-y If I had to pick only one flaw in Java. It would be its horrible and ugly GUI. I mean... it managed to make anything ugly.

I agree with the broader point that web tech is basically playing catchup with years of lag compared to existing technologies. However the one benefit we get from all this is real security and true universal runtime.

<comment><USER5> I remember that the official Microsoft JVM (which was quickly discontinued) used native Windows GUI controls to display the Java UI, and then later, the JVM on Mac OS X displayed Swing(?) apps with native controls. I thought it was all very neat, but against the interests of the companies.

<comment> yoz-y Java applications on mac had a very uncanny way of showing native controls. It is a bit like Qt, it kind of looks like a knock-off - elements are out of alignment, weirdly sized and so on.

</comment></comment></comment></comment></comment></comment><comment><USER6> From the description, it sounds like perhaps they transpile Java Bytecode to Javascript?

> Based on CheerpJ, a solution to convert Java applications to JavaScript, the > Applet Viewer extension compiles the Java applet on the fly, without relying > on any remote server.

<comment><USER7> Yes, from the FAQ: "The CheerpJ compiler, based on LLVM/Clang, as well as on parts of Cheerp, converts Java bytecode into JavaScript, without requiring the Java source. CheerpJ can be invoked on whole Java archives (.jar) or on single .class files, and generates a .jar.js (or .js) output. "

We've seen this plenty with GWT and the likes, but this one is self-hosted in the browser to support dynamic class loading. As with Emscripten, the real struggle is the stdlib, not the translation. As an alternative, I would recommend people look at TeaVM[0].

0 - [https://github.com/konsoletyper/teavm](https://github.com/konsoletyper/teavm)

<comment><USER8> Another related project is Doppio, an open source JVM written in TypeScript,

[https://github.com/plasma-umass/doppio](https://github.com/plasma- umass/doppio)

</comment></comment></comment><comment><USER9> It doesn't seem to detect applets loaded in <object> tags, only <applet> tags, and then only the first applet embedded on the page, which seems like an oversight. Specifically, this one:

[http://www.morenaments.de/euc/applet](http://www.morenaments.de/euc/applet)

<comment><AUTHOR> These are definitely bugs, please report them on the issue tracker here: [https://github.com/leaningtech/cheerpj- appletrunner/issues](https://github.com/leaningtech/cheerpj- appletrunner/issues)

<comment> le-mark One of notch's old java 4k games, fails to start? Cpu is pegged on a core, and the heap keeps growing. Notch used to write his own bytecode for these, would be a good test case me thinks! More of his games on this site.

[http://www.java4k.com/index.php?action=games&method=view&gid...](http://www.java4k.com/index.php?action=games&method=view&gid=288)

</comment></comment></comment><comment><USER10> Applets were/are a terrible idea, but they started us down a path of improvement that's lead us to where we're at today with browser technology.

I really wish we had a powerful virtual machine like the JVM in our browsers though... Client-side frameworks are making the web much slower and are eating battery life.

Web assembly is a step in the right direction, but the "not invented here syndrome" makes my head hurt.

<comment><USER11> What are features of the Javascript VM in current browsers that make it less powerful than the Java VM?

<comment><USER12> Single threaded, no 64 bit integers.

<comment><USER10> Also, dynamically typed (a feature rarely used and very costly)

<comment><USER5> What do you mean by 'rarely used'?

</comment></comment></comment></comment></comment><comment><AUTHOR> More information on the technology behind this can be found here: [http://blog.leaningtech.com/2017/06/announcing-cheerpj- java-...](http://blog.leaningtech.com/2017/06/announcing-cheerpj-java- compiler-for-webapps.html)

</comment><comment><USER13> can't wait to try running Runescape with this and watch my CPU explode.

</comment><comment><USER14> I wanted to try this out, since, my company still has some legacy code and we use swing/applet as our frontend. It has worked very well so far, but after NPAPI support has been dropped from Chrome and Firefox it getting tough to keep that as our frontend now. We have slightly moved to HTML5.

I installed and went to [https://www.java.com/verify/](https://www.java.com/verify/) on google chrome and still says "The Chrome browser does not support NPAPI plug-ins and therefore will not run all Java content. Switch to a different browser (Internet Explorer or Safari on Mac) to run the Java plug-in."

Am I missing something here?

<comment><AUTHOR> Click on the CheerpJ extension icon and and then click "Run Applets". Sites such as that one dynamically check if the Java plugin is available and CheerpJ needs to refresh the page to properly spoof the plugin availability.

</comment></comment><comment><USER15> The demo takes a minute to initialize (firefox, windows 10, surface 3 pro) then shows a window that ignores all UI conventions.

Yup, they got the applet experience nailed down perfectly :)

(Somewhat joking. The technology behind it is still extremely impressive)

</comment><comment><USER16> I want to make a browser plugin that runs a full Linux VM with OpenJDK and runs Java applications sandboxed in its own full OS. That way you get the full Java capabilities and can pass through hardware that you want, or maybe give it permissions like mobile apps. Could also run C#, native code, etc.

</comment><comment><USER17> Neat, gives Chromebooks some new options. I have a few things I'd like to try, like Dell iDrac.

</comment><comment><USER18> These demos allow you to test this tech without installing an extension:

[http://www.leaningtech.com/cheerpj/demos/](http://www.leaningtech.com/cheerpj/demos/)

It's kinda fun to see Swing again...

<comment><USER19> Funny. Just posted about Swing yesterday and, in particular, as a solution to what current JS frameworks are trying to achieve:

[https://news.ycombinator.com/item?id=14581407](https://news.ycombinator.com/item?id=14581407)

I'm not advocating traditional applets, but the Swing paradigm is actually near-perfect for the job.

</comment></comment><comment><USER20> > You are 2 clicks away from the applets you need or you love.

lol, so they're mutually exclusive?

<comment><USER21> No, otherwise it'd be "you need xor you love".

</comment></comment><comment><USER22> A similar project is shumway, an implementation of Flash with JavaScript: [https://github.com/mozilla/shumway](https://github.com/mozilla/shumway)

<comment><USER23> Shumway development has been discontinued. See [https://bugzilla.mozilla.org/describecomponents.cgi?product=...](https://bugzilla.mozilla.org/describecomponents.cgi?product=Firefox%20Graveyard)

</comment></comment><comment><USER24> I currently have to use IE10 to log in to my work's Citrix remote access solution as it is the only browser that still supports Java. I wonder if this extension would work for that?

</comment><comment><USER25> the only reason we use a java applet, is because javascript has no api to access a smartcard reader. unfortunately this project can not solve that use case.

<comment><USER26> this can change soon. [https://wicg.github.io/webusb/](https://wicg.github.io/webusb/)

</comment></comment><comment><USER27> I've been aching for a solution to run Webex on current browsers on Linux. Sadly, this doesn't appear to do the trick.

<comment><USER28> For what it's worth - you can do this with firefox(others may work, but it's my go-to for this process).

Short summary of the steps: 1) First try to join a webex, let firefox download and install the webex plugin 2) Look in ~/.webex, you'll see a bunch of 32-bit binaries 3) `ldd` on the 32-bit binaries, and install the 32-bit requirements to satisfy the missing dependencies. 4) Restart firefox, join the webex, you're done.

The big issue is that the plugin they download assumes you are using a 32-bit OS, and will fail to load without much in the way of meaningful error messages.

</comment></comment><comment><USER29> About time :) Lots of fun and useful things were applets (OK, mostly fun things).

It would be a shame to lose all of them (similarly for J2ME).

</comment><comment><USER26> Awesome piece of tech. However I guess this will not stay free forever.

</comment><comment><USER30> I hope there is ActiveX runner, so I did not rely on IE in Windows.

</comment><comment><USER31> I like it. Java is slow again! /s

</comment><comment><USER32> Lets start running android apps in the browser!

</comment><comment><USER33> The title seems a bit strange to me:

"without JVM" \- providing what is necessary to run Java _is_ a JVM in my book. That you compile Java to JavaScipt is just an implementation detail, isn't it? EDIT: Yeah, ok. It emphasises that you don't need an extra JVM on your computer.

"fully client side" \- isn't that how Java Applets always have been executed?

"no plugins" \- Not sure what you mean by "plugin". Installing an extension does not match that?

Hmm.. ok, ok I am nitpicking :)

Could you instead provide a bookmarklet that runs Java Applets on websites? That would be something I would use. I would not install an extension because I don't want your code to run outside of the browser sandbox.

<comment><USER34> Seems the extension converts Java to JavaScript before executing anything, that's why it gets by without a JVM.

<comment><USER35> Ah, so it's merely a machine that implements a virtual version of the Java runtime.

</comment></comment></comment><comment><USER36> And projects like this is why I use chrome. The gulf between firefox and chrome continues to expand.

</comment><comment><USER37> Java applets? 2005 called, they want their hackernews posts back.

<comment><USER38> Sadly, vendors are still shipping hardware that requires Java applets for critical functionality. (ASRock, I'm looking at you.)</comment></comment>


Expository Programming (2006) - <AUTHOR> http://archive.vector.org.uk/art10000980 <comment><USER2> A similar sentiment to Alan Kay's notion that "The computer revolution hasn't happened yet."</comment>


Serving frozen food without telling customers is fraud, rules top Italian court - <AUTHOR> https://www.thelocal.it/20170719/serving-frozen-food-without-telling-customers-menu-fraud-rules-top-italian-cassation-court <comment><USER2> Great idea to hold restaurants accountable for transparency with their clientele, especially in a country that as the article mentions, has a high amount of tourism due to their food.

</comment><comment><USER3> I think a better title for this article would be:

Ice Cream (Frozen)</comment>


Making game engines is a waste of time – I probably won't stop making them - <AUTHOR> https://benwiser.com/blog/Making-game-engines-is-a-waste-of-time---I-probably-won%E2%80%99t-stop-making-them.html <comment><USER2> My college has a senior project course every spring. The class is divided into groups of four to five members. Each group implements the same board game as a video game in a competition. The board game always is always deterministic with perfect information (i.e. chess or checkers).

Most team use Unity. Two years ago there was an unsuccessful attempt in Unreal, and three years ago an excellent game with web technologies (Electron + Angular).

I took this course last year and my team took a different approach. Our class's board game was Quoridor[1] and my group wrote a game engine[2] in Java leveraging OpenGL for graphics and Netty for socket abstractions.

The amount I learned that semester was incredible. Never before have I needed to know anything about graphics rendering, how to load fonts from a file and convert it into a texture format. I never needed to know about how to actually create a networked application, how to use genetic algorithms to tune AI weights, or put all of that together to create a game.

Our game sucked, but it was the most productive three months of my education and I learned more through that self-imposed struggle than my prior three years and a half years of classes. A game engine can touch any field in computer science and bring it into one application, and I think that's incredible.

[1] [https://en.wikipedia.org/wiki/Quoridor](https://en.wikipedia.org/wiki/Quoridor)

[2] [https://github.com/harding-capstone](https://github.com/harding-capstone)

</comment><comment><USER3> It's a bit unfortunate that this issue is so contentious on game development forums.

Someone wants to make a game engine, or asks for help with some aspect of making a game engine, and someone will often reply by saying "you should just use Unity" or something similar. It may be well-intentioned and they may give good reasons why you should just use engine X instead of rolling your own, but here's the big problem…

Before you help someone, you gotta understand what their motives are.

The next part is simple—if you're under no illusions that you are not making money by making games, the kind of dollars/time input, salable product output efficiency ratio just stops being relevant. So some _other_ factor is relevant, if you are a hobbyist.

<comment><USER4> > _Someone wants to make a game engine, or asks for help with some aspect of > making a game engine, and someone will often reply by saying "you should > just use Unity" or something similar._

That's also a classic BS response in Stack Overflow and such.

Someone asks "How do I do X?"

And people will jump to comment "You shouldn't do X, etc" instead of answering the question (and if needed, adding a caveat that they don't recommend it).

Many times people very well know the drawbacks of X, that it's considered a bad practice, etc, and also how to do it "the right way", but want to do X anyway for some specific reason (hacking, working around some issue, etc).

<comment><USER5> True, but _most times_ when asking for help, people are _not_ aware of the drawbacks, and are trying to solve a problem in a completely inefficient way.

[https://en.wikipedia.org/wiki/XY_problem](https://en.wikipedia.org/wiki/XY_problem)

So it's not so much of a "BS response" as a rational first response, even if frustrating for people who don't fall in that category.

<comment><USER3> It's well-intentioned but I would like to hold people to higher standards.

<comment><USER5> Why? Holding people who are beginners asking questions based on wrong assumptions to the standards of experts who are trying to push the boundaries with complete domain knowledge seems like a wrong thing to optimize for.

<comment><USER3> These aren't people asking questions.

These are people who make bad assumptions when they answer questions.

<comment><USER5> Apologies, wasn't sure who you were talking about.

The point is they're not bad assumptions, they're a pretty good prior. If you swing the other way and assume people "know what they're doing" and take their word for it, you're going to give them and yourself a lot of grief in a majority of cases ("but how do I put the gasoline in the chainsaw to cut the chicken?").

<comment><USER3> I used to think the way you do, but as I spent more time on forums like Stack Overflow, I started to see the damage that this kind of behavior does to the community. I now see this behavior as an opportunity for a teachable moment to explain to people how to answer questions.

It's one thing if you are on the DIY Stack Exchange and ask how to knock out a wall, and the best answer is, "That's a load-bearing wall. You don't knock it out."

It's another thing entirely when you ask innocuous questions like, "How do I tell what web browser and version my code is running in?" and some smartass answers, "You should be using feature detection."

It's really frustrating to ask a _straightforward question_ and to get a response from five different people making invalid assumptions about what problem you're trying to solve. It makes the community seem downright hostile! You may think that you're addressing the underlying problems—but what you're doing is telling people, "I don't take your questions seriously; I know better than you."

That might not be the message you _want_ to send, but if you rely on assumptions then it will be the message that you _do_ send.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER6> I have the same problem - love working on the game engine (I have several), but thankfully I found someone who loves designing games and drawing pixel art. Also, he doesn't know what "using RISC-V virtual machines with thin C++ binaries as a scripting language" means, so he can't complain about all the stupid shit I'm doing!

</comment><comment><USER7> Butchering Eisenhower's famous quote about planning in times of war:

> In producing a skilled game developer, I have always found that their self- > made engines are useless, but the development experience is indispensable.

</comment><comment><USER8> I'm reminded of Jonathan Blow's talk, "Preventing the Collapse of Civilization" [1]. Are we going to end up with a generation of game developers who don't understand the internals of their game engines? The unreal engine 5 demo has really wowed everyone but could we maybe reach a point in the future where these amazing game engines are struggling to compete against really inefficient game code?

[1] [https://www.youtube.com/watch?v=pW- SOdj4Kkk](https://www.youtube.com/watch?v=pW-SOdj4Kkk)

<comment><USER9> As soon as you want to do something the engine doesn't provide you have to start learning. This happens way more frequently than you'd think.

I still think a JASS-like code editor would have been better than blueprints for giving news a mental framework for transitioning into C++.

<comment><USER10> I'm curious what you mean by JASS, a search brings up things about card playing

<comment><USER9> Warcraft 3's scripting language it used in it's world editor.

Looked like this:

[http://world-editor- tutorials.thehelper.net/dialog/dodialog....](http://world-editor- tutorials.thehelper.net/dialog/dodialog.png)

</comment></comment></comment></comment><comment><USER11> I'm currently making a game engine myself and it has been both challenging and fulfilling.

I don't expect people to use what I've made, but as long as I learn from it, it is not going to be a waste of time.

Each step on making the engine has been full of important lessons:

* With OpenGL I learned about graphics and how they are rendered on a screen. Knowledge on this has helped with optimizations on my other projects made with Unity

* Adding Lisp scripting has renewed my love of Lisp and has made me realize the importance of scripting on game engines

* Implementing cross platform has made me realize just how difficult this is and why most people jsut go with Unity because it's offered out of the box.

* Designing APIs and functions is not trivial. Each game engine has a different way of doing things and it is mostly dictated by their technology stack.

I'm working on this mostly for learning purposes and I've been logging my journey every step of the way. If anyone is intetested in checking it out, or give suggestions or critiques, here's the link:

[https://github.com/accidentalrebel/Rebel-Game- Engine](https://github.com/accidentalrebel/Rebel-Game-Engine)

</comment><comment><USER12> We still need a world class, best of breed, open source game engine, no?

It seems like game engines should go the way of linux. No one would really consider making a new commercial os these days.

<comment><USER13> Have you checked out the Godot engine?

I don't think it's at the polish of Unreal or Unity, but it's probably the closest attempt for open source.

</comment></comment><comment><USER14> Today, building a custom game engine does not necessarily mean building everything from scratch.

A lot of very good open-source libs can be assembled to relatively quickly build a working engine tailored for the needs of the games you want to build.

SDL, bgfx or Diligent can be used a simple platform/rendering abstractions, many of the excellent stb libs can be used for resources loading, or Assimp if you need 3D assets, simple or complex physics engine are also available, same for audio and networking...

<comment><USER15> Most of what goes into a game engine is not those.

SDL is a similar level of abstraction to win32/x11/...

Bgfx/diligent have a similar level abstraction to d3d/opengl/...

(And if you are a solo engine-writer, you're not going to write more than one custom windowing/graphics target anyway, so those libs don't reduce the amount of work you have to do.)

A basic image loader for a format like bmp or netpbm is trivial.

Here are all the dependencies for my game engine right now:

\- Assimp

\- Freetype

\- SDL

\- Linear algebra library

\- Intel intrinsics library (transitive dependency of the math library)

\- S7 scheme

\- stb-image

\- Toml parser

\- Audio library

I estimate it would take under a week to replace all those except freetype and assimp, and freetype could be replaced with bitmapped fonts. Making an engine is as much (or as little) work as it's ever been because, similarly to a web browser or an OS, the challenge is designing and implementing application infrastructure.

      _______________________________________________________

More interesting, IMO, is to look at the ways that general-purpose engines have allowed people to avoid building engines in the first place. Something like unity is a toolbox to let you build any game you would want without _needing_ to write thousands of lines of infrastructure code. Even lighter- weight toolkits like love,fna,raylib are general enough to be usable for a broad variety of games, while still providing enough specific functionality that you can just start writing your game.

</comment></comment><comment><USER16> The general case game engine, such as Unity, are one size fits all. It can make sense to make specialized game engines that optimize for a specific gameplay dynamic.

</comment><comment><USER17> I love this mindset. I think as engineers we often get discouraged when we feel like our own implementation of something could never be as good as what's already out there (at least, I do). But the question that should be asked is: "Would it make me _happy_ to do it myself?" If so, then who cares! Hobby projects are about making yourself happy. There's nothing wrong with doing something purely for fun.

</comment><comment><USER18> It's unfortunate that everything has gone high-level (Unity/Unreal) or ultra low-level (Vulkan/Metal/DX12).

In the 2000s hobbyists were doing stuff in the middle level, because you had to stitch together your window management, GL/DX code, physics libraries, sound libraries, net code, input code, yourself.

I don't know that you always want to do that, but everybody ought to do it at least once.

</comment><comment><USER19> If you really want to make a game that doesn't give the user a feeling that they've played it before you do need to make your own engine.

You can tell in seconds that a game feels and renders like another game using the same engine. Sometimes the quirks and unique characteristics of a custom engine are what give a game its charm and X factor.

</comment><comment><USER20> I remember this urge, it took me once. I wrote a physics+animation engine for the Palm Pilot(!) and wrote a couple games in it - Lexicon and Combinoid. Moving sprites, collision, physics. Fun while it lasted.

Turns out there wasn't really a market for games on the Palm Pilot. Oh well.

</comment><comment><USER21> It's not a waste of time. For effectively using off the shelf game engines, you need to have a good understanding of what's going on under the hood. And the best way to learn that is by building your own toy engine.</comment>


Launch of ProGamer.app to let gamers earn real prizes - <AUTHOR> https://www.progamer.app/post/welcome-to-progamer-app-play-esports-games-and-earn-money <comment><USER2> I already tried it and it works good. However, it still needs more users to play with

<comment><USER3> which games it has? It has Brawl Stars for Android?

</comment></comment><comment><USER4> I think they are also developing a version for iOS, waiting for it.

</comment><comment><USER4> It works good! I already receive some profits from it. Good job</comment>


JetBrains has finally released CLion – cross-platform IDE for C/C++ development - <AUTHOR> http://blog.jetbrains.com/clion/2015/04/clion-1-0-has-finally-arrived/

<comment><USER2> If anyone has any insight what CLion might bring to the table that I can't get from QT Creator, I would like to know. It seems that $99 for an individual license is high, but up there in price along with AppCode

<comment><USER3> I haven't used QT Creator. Does it have many refactorings like Rename function, Extract function, etc? I'd suggest you watch this video to see if it would be beneficial to you : [http://blog.jetbrains.com/clion/2014/12/refactorings-in- clio...](http://blog.jetbrains.com/clion/2014/12/refactorings-in-clion-be- safe-and-quick/)

<comment><USER2> Thanks. This feels a lot like Sublime Text to me after watching that.</comment></comment></comment>


Thiel: Technology Stalled in the 1970's - <AUTHOR> http://www.technologyreview.com/qa/530901/technology-stalled-in-1970/ <comment><USER2> What drivel, consider Theil's comment, _" We could be finding cures to cancer or Alzheimer's."_

This is somebody who watches Star Trek and figures that if they can use dilithium crystals to control anti-matter plasma conduits, well gee how hard can it be? We should get right on that.

I'll cut him some slack because he wasn't actually alive in the 70's but seriously, cure cancer? Is he not aware of the billions of dollars of investment in that problem? Did he not even realize that the cell biology research that came out of figuring out AIDs wasn't even freakin' _POSSIBLE_ in the 70's? You couldn't do analysis on DNA in the 70's because the machines that did that, would take until the present day to give you an answer. Think about that.

Famous quote from Marvin Minsky along the lines of you want to solve a problem that will take a million hours of compute time, you can either spend a ton of cash and buy a super computer, and start it on its way and wait 114 years, or you can invest the money you have in a savings account, wait 20 years and then buy a computer at Fry's that will solve it in an hour.

We couldn't even build the tools to build the tools yet in the 70's that we regularly use to put cool features into an iPhone today.

So basically I'm offended on behalf of every engineer who lived and worked in the 70's at his comments.

And then lets take the flipside, given that we do have all of these amazing tools at our disposal, do you think people are _not_ trying to cure cancer, in all its forms? So Peter has some genius idea that the Memorial Sloan Kettering Cancer Center's staff of doctors _isn 't_ considering?

Technology did not "stall" in the 70's. It has been accelerating at an exponential rate for decades. I can't believe he really thinks that.

<comment><USER3> I kinda feel like you're getting too bogged down in the detail here. I don't think anybody would agree that Thiel is literally 100% correct in saying "technology stalled in the 1970's, but if look look at the statement as a bit of hyperbole with a kernel of truth to it, he has a point. And whether you agree with him in general, or not, I think his rhetoric serves a valuable role in terms of encouraging people to reach further, and work on big, hard, fundamental problems.

Anyway, I don't see what he said as being a statement like "I, Peter Thiel, could trivially cure cancer" or anything like that.. I see it as a call to arms to people who are working on, say, ad serving networks, to work on curing cancer instead (where "curing cancer" is a variable that could be replace with any "big, hard, fundamental problem").

<comment><USER2> Except I think Peter misses the point. He's asserts technology is moving "to slowly" or "to inefficiently" and doesn't seem to have any appreciation for the prerequisites for forward motion. And he dismisses out of hand anything people have done while that foundation is being build. As if having them sit idly by would have been a better use of their time?

Imagine you're building a castle, and you've got a quarry full of people cutting the stones to build it, and then you chastise the carpenters who are working on decorative woodwork because there is not enough castle yet to work on.

Sure, Google has spent a ton of money building an ad network and figuring out how to get people to click on ads. They have also spent a ton of money on building phone OSes, and build tools, and efficient data centers, and self driving cars.

Not everyone can work on curing cancer or creating durable political institutions that survive local corruption. So what do they spend their time on? Building tools, or using those tools to build interesting things which feeds back into better tools.

I didn't see any appreciation of the foundational work that has to happen in order for progress to be made in that interview.

</comment></comment></comment><comment><AUTHOR> Alan Kay famously asked if there was any new invention in computing since 1980 (and the answer was essentially 'no'):

[http://stackoverflow.com/questions/432922/significant-new- in...](http://stackoverflow.com/questions/432922/significant-new-inventions- in-computing-since-1980)

Our whole industry got sucked into making a fortune and now suffers (ironically) from "The Innovator's Dilemma".

We have more money than Croesus now, but at the expense of any real progress.

</comment><comment><USER4> As an alternative to the subjective impressions of Peter Thiel or of people here, perhaps we could adopt a more objective approach, relying on empirical evidence. I propose looking at productivity growth: [https://en.wikipedia.org/wiki/Productivity](https://en.wikipedia.org/wiki/Productivity)

<comment><AUTHOR> First, I think he is talking about larger projects, with larger leaps of faith. Small, incremental gains in productivity and chip speed are fine, but we can do more; we have the potential do amazing things and we're not even trying.

Second, productivity growth would normally be good if the gains from that growth were distributed. Instead, all of those gains have been placed directly with the wealthiest %1. So instead your graph, sadly, simply reflects how the quality of life has degenerated over the generations. That's not the kind of progress that 99% of the world was hoping for.

<comment><USER4> First, what Thiel is trying to do (which neither of us will know for sure) is irrelevant to the question of what other approaches we might adopt for answering variations on the question, "How has the pace of technological development changed, if at all, over time?"

Second, how those those gains are distributed is likewise irrelevant to that particular question. Not that they're irrelevant to other questions, or that they're unimportant, or uninteresting, or that this is the only question we can ask. The careful reader will notice that neither Thiel nor I really commented on the otherwise important and interesting question of how gains are distributed. That's just something you threw in.

Third, it's not "my graph." I linked to a Wikipedia article written by other people and which contains no fewer than four graphs at the time of this writing, and none of them were created by me.</comment></comment></comment>


Using Amazon Auto Scaling with Stateful Applications - <AUTHOR> http://adrienmagnus.com/using-amazon-auto-scaling-with-stateful-applications <comment><USER2> Glad to see writeups and lessons learned about AutoScaling. As a system builder, I think it's a capability that's under-appreciated. My rule of thumb is that essentially every machine fleet benefits from being managed as an AutoScaling Group (whether stateless or not - there's value even without dynamic scaling).

> If you're working with a queue based model then scaling will be done based > on the SQS queue size, otherwise we'll use the custom metric "number of > running jobs".

There is another strategy to consider when auto-scaling queue-based applications: if you have a fixed number of threads per machine instance that process work from a queue, then you can scale based on the percentage of threads occupied.

You can treat this as a utilization percentage similar to CPU Utilization, the observation being that you can begin scaling up in advance of ever actually developing a (long) queue. For example, consider an application where the average queue size is zero, and the average thread utilization is zero. Consider another application where the average queue size is zero, because messages are processed almost immediately, but 19 out of 20 threads are occupied on average. You can conclude that the first application is nearly idle, while the second is nearly maxed out, even though both of them have empty queues. By considering the second application to be (19/20=) 95% utilized, you can establish a scaling policy that scales up before a backlog develops if you wish -- this is assuming that you wish to avoid developing a long queue, which is desirable in some cases. It depends on how quickly you'd like to process messages - SLA.

(The article touches on this as well, talking about number of running jobs.)

Queue size can be useful as well, but I think it can be more difficult to tune. Percent of thread capacity works well regardless of how large your fleet is, and how expensive messages are to process. By comparison, a large-scale system that processes thousands of messages per second could develop a large queue -- in terms of number of items -- from a brief blip, which it will burn through momentarily. A 20,000 item queue might be nothing to such a system, whereas for another system, 100 items could be significant, if each one is a 10GB video to download and transcode.

The ideal auto-scaling solution typically involves a mix of multiple measurement techniques, since it's rare that any single performance characteristic captures an application's load perfectly. I would definitely agree with the author's point that instrumentation is highly valuable.

<comment><USER3> Queues should be measured in wallclock time, not in terms of items. That removes the problem you mention.

<comment><USER4> The only other consideration is stress of jobs on peripheral resources like the database. If you have multiple jobs that may be intense enough to insist on sequential execution it could inflate a wall clock number even if scaling wouldn't matter.

You essentially need a metric for wallclock time exclusive to jobs that benefit from scaling.

</comment></comment></comment><comment><USER5> You'll want to make sure you don't autoscale just because a shared resource like a database is not working correctly. There's no point in having more instances up if the new ones don't work either.

Elastic Beanstalk can be very useful, especially for deploying new versions of your app. It has a CLI that makes it easy to SSH to all of your instances as well. And application environments can be configured to save its logs to an S3 bucket. And it has support for time-based scaling events, so you can have more hosts up during the day if that's what you need.

<comment><AUTHOR> Good point, and that's when good monitoring comes into play.

</comment></comment><comment><USER6> I would be curious what variance of load would be required for this type of auto scaling to be worth the time vs just putting your own bare metal in a colocation facility or leasing dedicated boxes.

The price performance is so much higher on dedicated. Or for that matter, using reserved instances instead of scaling with spot prices.

<comment><AUTHOR> It comes down to the business decision of going all in with cloud or bare metal. Day to day management of each is pretty different.

</comment></comment><comment><USER7> Stateful applications should use horizonal autoscale to hot-add CPUs. While this has a lower limit than vertical autoscale, the two can be combined with sticky persistence to maintain state at scale.</comment>


Read Almost any Amazon book for Free - <AUTHOR> Find the ASIN of an Amazon book on Amazon's site then put in this url: https://read.amazon.com/?asin=REPLACE_ASIN_HERE Try: https://read.amazon.com/?asin=B0064CPN7I https://read.amazon.com/?asin=B003H3IOXM https://read.amazon.com/?asin=B0045JKJ7G <comment><USER2> It lets you read only sample content of the book. You can read it on Amazon site for all books by default.

</comment><comment><USER3> Good trick but you have to sign into Amazon to activate the offline reader for Amazon Kindle Cloud reader. If not then it won't work. Also it seems to go to a part of the book instead of the first page or cover. Perhaps it reads the history of the person who last accessed the ebook in that way?

I guess Amazon will shut it down eventually or check permission for the ebook before letting you read it. I write ebooks and had one published on Kindle with my Orion Blastar character that I am always reinventing.

<https://read.amazon.com/?asin=B007LAX6YY> for those interested in the book. See if it works.

For some reason it is also here:

<https://read.amazon.com/?asin=B007M4AACA>

But it only includes the copyright page, and the rest of the ebook is gone. I submitted a new copy that fixed formatting errors, but later found out MS-Word 2010 corrupted my original data file on my hard drive. I did a recovery and switched to LibreOffice because MS-Office kept giving me problems.

I am in the process of rewriting the ebook, and I can see why people had an issue with it, I'll try to get it reuploaded if all that is showing up is the copyright page.

Thanks for the info, it shows me that the readers get a different version of the ebook than what I get as the author. I didn't know the ebook only had a copyright page for the updated version, when I previewed it in the Amazon Kindle preview program it was the whole ebook and not just the copyright page. So this little 'hack' actually helped me as an author.

<comment><AUTHOR> Yup you do have to sign in, but it definitely lets you see the entire book, it just starts on a random page it seems.

<comment><USER3> Even stranger my second link makes it a 'sample' ebook which is why only the copyright page shows up. It is a short story like 16 pages, and I hoped to develop it into a full novel eventually. I wanted feedback from readers before writing more of it. Yet the first link is the original first edition before I made any changes to it, and you can read it formatting errors, etc and all.

Also the first edition did not have hyperlinks but the second edition did.

Oddly enough it does work somewhat. I wonder what other ebooks are sample only and which ones are the full version?

Anyway I just uploaded a new edition of the ebook, in 24 hours Amazon will approve or reject it. I wanted to give it away for free, but Amazon limits that, not only that but the lowest I can charge is $0.99USD and they won't let me self publish it to other ebook stores.

If anyone wants a free copy, email me at email@example.com if interested.

</comment></comment></comment><comment><USER4> Its a misleading statement. Please change it to "Read sample pages for most Amazon books". or take this post down, it has practically no value.

</comment><comment><USER5> Wow. There's a hole big enough to drive a truck through.

<comment><USER6> It only shows book previews...</comment></comment>