Show HN: My time tracking tool for your text editor - <AUTHOR> https://www.wakati.me/ <comment><USER4> Great concept, but I'm not sure how comfortable I would be with a plugin that sends a list of active files to a website (even if it is SSL-secured).

<comment><USER5> It would be a great concept for a "unhosted" application.

</comment></comment><comment><USER6> A really cool idea, but probably not useable by anyone working on proprietary software, I'm afraid. I'd love to use it as a productivity app - <USER2> if you could segment the data based on the active git branch - <USER3> transmitting file information over the wire is a non starter for myself (and I imagine many others).

Have you considered maybe supporting output via some sort of graphing language instead? (R springs to mind.)

<comment><USER7> Just curious, would you have made the same arguments against RescueTime? It too transmits your activity data (and who knows what else) over the wire.

I don't know if you use(d) RescueTime or not, so I don't mean it as an attack against you. I guess I just don't remember these types of arguments being leveled against RescueTime (maybe I'm wrong about that, but a quick search didn't reveal anything) and I'm curious as to the reason. Is it b/c of the recent privacy concerns being raised by the US govt's actions, that RescueTime had more cachet when it launched, they got the messaging right to alleviate these concerns, or something else?

<comment><USER6> I actually have used RescueTime. I would have probably raised the same concern except that I was using it, at the time, at the encouragement of my employer. If they were fine with it, then so was I.

I haven't continued to use it, but to be honest I haven't given it much thought.

<comment><USER8> I would like to know your thoughts about using Codeivate. Also what other time tracking app do you use?

</comment></comment></comment></comment><comment><USER9> I would be able to use it if there was a way to just keep the data only in my computer.

</comment><comment><USER10> For those looking for a local-only version of time tracking; I've had this in my vimrc for some time now. It's quite vanilla but gets the job done

[https://gist.github.com/goatslacker/6004481](https://gist.github.com/goatslacker/6004481)

</comment><comment><USER11> Just some somewhat-constructive feedback: It's always a pet peeve of mine to see the default bootstrap theme on new web apps. It doesn't take a lot of effort to customize it and doing so goes a long way to provide a sense of authority about your application.

I know it doesn't seem like that big of a deal (and for all I know, I could be alone with this sentiment) but it makes a world of difference for me.

That being said -- this looks awesome and I look forward to getting some consulting work to try it out.

<comment><USER12> Doesn't bother me in the least.

Bootstrap offers sane defaults and presents users with a familiar experience.

If my choices are color/design decisions made by someone who's specialty is something else, or just vanilla bootstrap, I'd encourage the latter.

<comment><USER13> I agree.

</comment></comment></comment><comment><USER14> Cool idea,

My problem with this type of granular time applications is that they are to granular :)

I don't only work on a project when I'm typing on a text editor. I actually do a lot of thinking before using a editor in fact the actual time I spend in the editor is maybe 60% of the time I work on a project.

So for my case I will have to use it with some other time tracking tool witch is to much of a hasel.

Keep us the good work, I am sure there is a market out there for this.

<comment><AUTHOR> Yea it's not perfect, but you could just open a file and leave the editor open while you do other things for the project.

</comment></comment><comment><USER15> Cool. I just use org-mode in Emacs which tracks all of my tasks and puts a nice little timer in my status bar. It saves everything in plain-text and I can export it to various formats such as HTML or PDF as needed. I'd take a look at it for inspiration if you're interested.

<comment><AUTHOR> I was using Org-mode but found it hard to actually use the data I was logging. That's where WakaTime started.

I also hated when I forgot to check-in or check-out from a task in Org-mode and had to guess about a timestamp. The whole experience was tedious.

With WakaTime I have many possibilities for data visualization and reports for my side-projects and contracts.

</comment></comment><comment><USER16> For those of you who were commenting and looking for a local only timetracking , I have a git plugin that supports Redmine timetracking, and is git friendly. Also, works for gitbranches and git repos, tracks by repo/by branch or annotated tag - does some other stuff - got to stop adding random features.

[https://github.com/PAntoine/TimeKeeper](https://github.com/PAntoine/TimeKeeper)

(EDIT: correct url/project)

</comment><comment><USER17> Cool idea... It took over my ST2 though. When trying to enter the API key, the console flashed wildly with a _couldn 't find api key_ message of sorts. Then, when I finally got the API key to be accepted, I was unable to access package control via ctrl+shift+p. That functionality was replaced with another cmd window that instantly closes. Not sure what the deal is with it, but I'm uninstalling for now.

<comment><USER18> How did you uninstall? If I remove it from the packages folder it just installs it again.

<comment><USER17> I just opened my User/AppData/Roaming/Sublime Text 2/Packages folder and deleted it... It hasn't re-installed for me.

</comment></comment></comment><comment><USER19> How does it know if I am doing useful work? If I just leave me vim window on and leave for lunch, will it know I am idle or log the time? Also, opposite scenario, when I am concentrated on something, I basically read the code for a good 30-35 minutes, without typing anything into vim. Can it distinguish it as useful work rather than otherwise?

<comment><AUTHOR> Scenario 1: You leave Vim to read HN for a while.

WakaTime will ask you when you return if you want to log that time to the current file or not. This happens if you're away for > 15 mins.

Scenario 2: You are reading code without editing it for 30 mins.

At wakati.me you can check the "save" checkbox to filter out any files/projects that were not written to. That file where you did not make edits won't be shown on the website.

</comment></comment><comment><USER20> Great idea for a plugin, but it made my Sublime Text 2 install unusably slow. I'm not sure what could be doing that - the fact the developer suggested installing bind to cache DNS requests makes me think it checks in with the site very often and I have a poor internet connection where I am right now.

</comment><comment><USER21> I'm currently making use of Codeivate - [http://codeivate.com/](http://codeivate.com/) \- it's pretty awesome!

You can check my progress here, [http://www.codeivate.com/users/jbrooksuk](http://www.codeivate.com/users/jbrooksuk)

</comment><comment><USER22> Do you have a bug tracker?

When I left my computer for awhile, I'm now getting infinite "You were away 17 minutes. Add time to current file?"

It's possible that it's not infinite and I just have THAT many files open, but gah. I have to uninstall this plugin for now. Let me know when it's fixed!

<comment><AUTHOR> [https://github.com/wakatime/sublime- wakatime/issues](https://github.com/wakatime/sublime-wakatime/issues)

I've temporarily switched to using Sublime instead of Vim so that bug will get fixed today.

</comment></comment><comment><USER23> Does this track time even when the window is unfocused? If possible, it shouldn't: I often leave my editor open but idle even for hours, and this might skew the tracking by counting a lot of time on a file on which I didn't really work for that long.

</comment><comment><USER24> We do something pretty similar with PaymoPlus but it works with any app [http://www.paymo.biz/paymoplus](http://www.paymo.biz/paymoplus) \- not sure why you would limit the app only to text editors.

<comment><AUTHOR> I limited it to text editors because I was making this for myself and I'm a programmer.

I wanted to visually see the data I was already tracking with Org-mode and also wanted my time tracked without my involvement.

</comment></comment><comment><USER25> Tried it out, the search in file went really slow. Also, when I was away, it asked me if I wanted to log the away time. That's fine but opening up dialogs until Sublime crashes, not ok.

Will try it out more when/if those two things are fixed.

<comment><AUTHOR> It's probably slow now because of the HN load.

Right now I don't have a better way to log AFK time besides the dialog. Just to clarify, are you worried about Sublime crashing while you're away?

<comment><USER25> No, the whole plugin is slow. When I search for things for example, Sublime is slow. The website is not slow.

And no, I'm not worried about Sublime crashing when I'm away. The dialog that pops up when it asks you to log you time, popped up like a thousands of times and then Sublime crashed.

</comment></comment></comment><comment><USER26> some portion of my project time is while in an text editor. some portion is not. and use a variety of editors and tools. so if it only captures a narrow subset of my actual spent project time, it's not a net-win for me personally. easier to start/stop a stopwatch of some kind. since that's out-of-band, it's automatically inclusive of all activities, whether an editor involved or not. reading time counts, thinking time counts, meetings, phone convos, etc.

<comment><AUTHOR> Would a day planner view solve this? That view would show you blocks of time for the day so you could see when you started working and when you stopped working without worrying about the meetings or breaks in the middle.

<comment><USER26> I think the MUT (minimum useful tool that nails it) would be like a stopwatch app/command, that also lets you specify what project (and optionally task within the project) is being started/paused/resumed/completed. Then it can show you total breakdowns by project, task, etc. In a completely private and local way. In a terminal. With GUI only as an optional bonus. This may already exist and I just am ignorant of it. Seems like an "old" problem that should have been solved by now and I just haven't stumbled upon it. I could write it I guess. But yeah, I don't want a desktop GUI or web app, by default. Give me a CLI in a Terminal. With text, I can then have lots of easy/obvious ways to slice and dice that, script it, etc.

</comment></comment></comment><comment><USER27> Awesome idea. Getting devs to track time is always a pain, and this kind of thing is a great way to get the data needed for less-annoying project management.

</comment><comment><USER28> How is this different from [http://rescuetime.com](http://rescuetime.com) (other than only tracking the text editor)?

<comment><AUTHOR> Good question. WakaTi.me knows what project your working under while rescuetime.com only knows that your inside your text editor.

<comment><USER28> That makes sense.

RescueTime gives me information about how much time I spent in each file and is showing me the project as part of that info, but it doesn't rollup time spent in a project.

Still seems of limited use since it wouldn't show me time spent debugging in a browser, working in the database, etc. From a productivity standpoint RescueTime lets me dictate that [http://myproject.dev](http://myproject.dev) is "debugging" time, Sublime Text is "IDE" time and that Terminal is also "development" time. If I could change how Sublime Text displays info in the title bar then I could probably set it to know that "Sublime Text -> My Project -> file" was time spent in "development/my project".

<comment><USER29> Actually, RescueTime does know and report on what file / project you have open inside the text editor, as long as the info is in the window title (which both these apps do). And it's keyword-searchable by whatever is in that data point-- usually filename, project name, directory tree etc. It works this way with just about all text editors.

The key word search method is how people usually accomplish the idea of project reporting-- but is admittedly not perfect, like you could get if we actually could consume that meta data.

However, the "document" level details are only exposed to you in the premium version-- in the free version you just get an open document count, so that is a significant difference.

I've always thought the long term path for an enriched time measurement experience would involve plugins like this one. Great to see someone working on it.

Disclosure: I'm a RescueTime employee.

<comment><USER28> Ah, I am a premium member, so that makes sense that I saw that in my dashboard.

</comment></comment></comment></comment></comment><comment><USER30> Nice. I signed up for an account and installed the sublime plugin. Is there any way to export data? Even if it's just an API for now.

<comment><AUTHOR> Yes, I have a JSON api that the Backbone.js website uses. To export all of your logged time, just page through this resource:

[https://www.wakati.me/api/v1/actions?page=1&show=file,is_wri...](https://www.wakati.me/api/v1/actions?page=1&show=file,is_write,project,tags,time,endtime)

I'll publish api docs soon to make writing your own plugin easier.

</comment></comment><comment><USER31> This is a great idea but would love to have the same thing for org-mode with git commit message integration

</comment><comment><USER32> There is bug on the windows when I changed file terminal window popup.

</comment><comment><USER33> If it worked with TM2 I'd use it.

</comment><comment><USER34> Really nice idea. I like it :)

</comment><comment><USER35> Dat inserted content

</comment>


Ask HN: SaaS Frameworks for Startups - <AUTHOR> Everyone's rolling out their own tech stack / framework solution or putting significant effort researching and putting the pieces together.
@patio11 wrote about how someone needs to create a book on it: https://twitter.com/patio11/status/1219997892028448768
Know of any frameworks/stacks built specifically for SaaS startups? Something that covers al the moving parts - Auth/Roles, Billing, APIs, CRUD, Logging and so on.
Language is irrelevant but preferably in the popular ones most people already know. PHP, JS, Python, Ruby etc. <comment><USER2> There are a few companies selling all of that in a single package as a SaaS boilerplate application:

If you like PHP - [https://spark.laravel.com/](https://spark.laravel.com/)

If you like Ruby on Rails - [https://bullettrain.co/](https://bullettrain.co/), [https://www.getsjabloon.com/](https://www.getsjabloon.com/), [https://railskits.com/](https://railskits.com/)

If you like NodeJS - [https://usegravity.app/](https://usegravity.app/)

If you like ASP.NET - [https://aspnetzero.com/](https://aspnetzero.com/)

If you like Python/Django - [https://djaodjin.com/](https://djaodjin.com/)

I can't specifically recommend any of them, as I never used, but I used another one built with Rails+EmberJS that was worth the money (I am not sure if it's still supported these days, but here it is [https://www.maxiomapps.com/apps/application-starter- kit/](https://www.maxiomapps.com/apps/application-starter-kit/)).

If you want to build a SaaS web app for problems that don't require cutting edge technology to be solved (aka most of them), I think buying one of those is a no-brainer in terms of cost/benefit.

</comment><comment><USER3> There are SaaS solutions for some parts that you mentioned. Examples:

\- Auth0 for authentication

\- Stripe for payments

\- Billomat for billing

For other parts there are good open source frameworks, for example:

\- Hasura for building an API on top of a Postgres data schema

\- Frameworks like Flask, Rails or Django for building a backends

\- Frameworks like React or Vue for building a frontend

\- Static site generators like Hugo or Jekyll for building your website

\- Hosting companies like DO or Linode and cloud providers like AWS or Microsoft Azure to host your services

There are also more tightly integrated solutions for specific niches like e-commerce (e.g. Shopify), if you build a SaaS solution you will probably have too many aspects that are unique about your idea to use such a highly standardized solution.

<comment><AUTHOR> All good suggestions. Adding to this, there's a thread full of similar gems: [https://twitter.com/flybayer/status/1220406529901223936](https://twitter.com/flybayer/status/1220406529901223936)

I do get that not all of these can be done and many are specific to niches. But I believe a lot of boilerplate can be done by one framework.

And an opinionated framework can do a lot. Say Payment integration modules (Stripe, Paypal et. al), Logging & Error Reporting, Opinionated Backend/Frontend and storage for basic CRUD, CI/CD integration and deployment workflows working with cloud providers, tight integration with a messaging queue etc.

Something like this could be a massive time saver in communities like Indiehackers.

</comment></comment><comment><USER4> Interesting checklist in one of the replies: [https://github.com/stockandawe/saas-startup-cto- checklist/bl...](https://github.com/stockandawe/saas-startup-cto- checklist/blob/master/README.md)

</comment><comment><USER5> Laravel Spark[0]. It costs $99 to get a license for a site/$299 for unlimited sites, but then you are pretty much set.

0: [https://spark.laravel.com](https://spark.laravel.com)

</comment><comment><USER6> I'm working on [https://divjoy.com](https://divjoy.com), a tool that generates custom React codebases. It doesn't yet cover everything a SaaS app needs, but Stripe integration, CRUD, db, etc are coming this year.

</comment><comment><USER7> I met the founder of [https://usegravity.app/](https://usegravity.app/) yesterday. Interesting guy and product.</comment>


Hatari: An Atari ST/STE/TT/Falcon Emulator - <AUTHOR> http://hatari.tuxfamily.org/ <comment><USER2> If you're interested in playing with an Atari ST but don't want to install anything, there's an in-browser emulator on my website here: [https://jamesfriend.com.au/pce-js/atari-st/](https://jamesfriend.com.au/pce- js/atari-st/)

<comment><USER3> Was the high resolution screen that I remember really that low?

<comment><USER4> Monochrome was that insanely high 640x400 resolution.

<comment><USER5> You could do a hardware overscan tweak and get over 800x480. I seem to recall I ran at 832x600 most of the time.

</comment></comment></comment></comment><comment><USER6> That's so cool. There's a few old programs I'd love to see but since it's been over 30 years I can't recall their names.

\- A music composer that took advantage of the MIDI ports. Connecting the software to synths etc would allow the Atari ST to not only control the synth, but also to record the music in note form as it was played.

\- A BASIC interpreting environment. Noteworthy for no reason other than this was the place where I wrote my first program ever.

\- A desktop publishing application with similar functions to the early Pagemaker.

<comment><USER7> > A music composer that took advantage of the MIDI ports.

Cubase or C-Lab Notator.

> A BASIC interpreting environment.

GFA BASIC.

> A desktop publishing application

This may be Calamus. Interesting fact: "an Atari Desktop Publishing system consisting of an Atari Mega ST computer, mono hi-res monitor, SLM804 printer and desktop publishing software cost less then an IBM or Apple laser printer alone." [1]

[http://www.atarimuseum.com/computers/16bits/printers/laser/s...](http://www.atarimuseum.com/computers/16bits/printers/laser/slm804.html)

<comment><USER8> Timeworks Publisher ST was another desktop publishing app for the ST.

</comment></comment></comment><comment><USER9> I remember going through lengths to make my old Atari ST look like a Mac. I installed the Monaco font and wrote a program, in assembly, to draw rounded corners on the screen like the Mac had. Now I sit on a MacBook Pro and I am trying to run Atari ST on it. Full circle.

</comment><comment><USER10> Nice, had an Atari 800XL, then a 512STfm, and then I was one of the 3 people who purchased a Falcon 030.

Learned Atari basic from a 2 page leaflet that came with my 800XL when I was 8, then progressed through True Basic and GFA Basic.

<comment><USER11> This sounds exactly like me, except I didn't make it to the Falcon. I always wonder if I should have gone C64 > Amiga, there just always seemed to be more stuff available for them. I did love the ST though.

</comment></comment><comment><USER12> This is awesome! I wish I had kept my old ST disks haha.

Apps I remember:

Revenge of the Mutant Camels remains one of the best games ever.

Calamus was also a great piece of software that predated Pagemaker for many years.

Heroes quest, police quest series of games.

There was an animation/tweenijg app for animation that blew me away.

These machines were great substitutes for amigas of the day.

<comment><USER13> While Calamus was indeed a great piece of software (IIRC, Linotype-Hell actually sold a very high-end printing system using an Atari ST and Calamus as the control system for a Linotype Imagesetter), it did not predate PageMaker. Aldus PageMaker came out in July 1985; Calamus DTP came out two years later, in July 1987.

Calamus -- at least as a brand -- _outlived_ PageMaker, though! Invers Software, the owners of Calamus, shut their doors only last year, but the web site is still up; a macOS descendant of Calamus called "iCalamus" appears to still be in active development, under relatively new owners (who are longtime Macintosh developers).

[https://calamus.net](https://calamus.net)

[https://www.lemkesoft.de/en/products/icalamus/](https://www.lemkesoft.de/en/products/icalamus/)

<comment><USER14> There was also for a while a native Windows NT version of Calamus (they even had Alpha et al versions, if I remember correctly) that was quite good; I used it to make money for quite a long time, and although by now I guess there must be something that approaches its functionality (haven't followed DTP world in years), at the time it had features that Quark or Adobe couldn't touch.

<comment><USER13> I think the NT -- well, later Windows in general, I guess -- version is the one that kept going until 2018. I'd always heard good things about it, but was over on the Mac side of the world with PageMaker and later InDesign. (While I'm still over in Macworld, when I need to do DTP-ish things these days, they tend to be in LaTeX, so I never actually looked up iCalamus, although I feel like I should give it a test drive sometime.)

<comment><USER14> It well might have been. I was beta-testing it the North American publisher (and got it for free, although they made quite a bit off me on Calamus SL and plugins for Atari TT030 I had before), even for a while after they sold to... Roxio was it? I can't even recall by now, but development was done in Europe.

They did some really nice things with virtual objects, being able to zoom in down to a printer dot, stochastic rasterization and all that.

There were some other very high-end packages for Atari as well --Didot, Retouche Pro, TMS Cranach. For some reason European developers really went wild developing professional-level DTP software for Atari with some very impressive results. Too bad Tramiels didn't do much to support them...

</comment></comment></comment></comment></comment><comment><USER15> Note that you can have a fully open-source retro experience by using EmuTOS (a free operating system for Atari computers) with Hatari: [https://github.com/emutos/emutos](https://github.com/emutos/emutos)

</comment><comment><USER16> I have a box of about 200 disks for this, and I've been keeping that old Atari ST alive and in use. Looks like it's time to convert once and for all. Just added a floppy disk drive to my Amazon list, here we go.

</comment><comment><USER17> Hatari was also the starting point for "Previous", the NeXT Computer emulator, and some code has been submitted and included from that project for 68030/040 MMU functionality.

</comment><comment><USER18> I remember running Ultima 6 and installing - using the hard disk option - to a RAM disk. My friend had a 4MB RAM expansion. I was basically having a 2MB hard disk in RAM!

I'd load the whole of U6 from 4 floppy disks, then fire it up and play, and when done, I'd save my position and copy it all back to the 4 floppy disks!

What helped were 2 things:

        *Utility to format disks to high capacity
        *Fast shareware disk copy utility

</comment><comment><USER5> Wow, brings back memories. All the software I wrote for the ST, the voicemail system I wrote for the Falcon, working on MiNT / MultiTOS. Fun times.

I'd really love to boot up Spectrum Holobyte's Falcon again, but with the CPU clock goosed up so it could get higher framerates...

</comment><comment><USER19> I wish the Amiga had a similar development community.

Unlike EmuTOS, AmigaOS is still closed, proprietary code.

Unlike Hatari, we've got winuae (windows-only) and a bunch of feature-cut, special purpose and/or abandoned ports to other platforms.

</comment><comment><USER20> Wouldn't it make more sense to add support for this machine family to QEMU? 68k cpu emulation is already included in QEMU, all it needs is general support for the platform itself.

<comment><USER21> Systems like the ST and Amiga used custom HW chip sets for things like graphics and sound. It is not just about emulating the CPU.

<comment><USER22> Yes. More importantly, for game and demo compatibility you need to tie HW chip emulation on cycle level with the CPU. QEMU would get more on the way than help.

</comment></comment></comment><comment><USER23> Nice!

I never had an Atari ST (stayed with Commodore to the bitter end, plus Tandy happened soon after) but I am glad someone out there is dedicated to keeping these 16/32-bit computers alive.

<comment><USER24> Heh, I had a similar path, starting with a Commodore 64 (where I learned Basic out of a magazine), moved on to an Atari STE, then onto an Olivetti (Tandy was big around the same time). Makes me feel very nostalgic :`)

</comment></comment><comment><USER25> I long for the ability to increment/decrement values with the left and right mouse buttons, particularly in Cubase.</comment>


Show HN: Garden Madness, a flowery HTML5 game - <AUTHOR> http://www.thearca.de/gardenmadness/

<comment><USER2> I see the brick/block popper game a lot (I have a games portal and I check out the 'new stock' pretty much every day).

On thing that I notice that the better brick-block-popper games do is that they start with far fewer colors. Maybe just three or four types of flowers (you might run in to layout problems on that one). As the levels advance in difficulty, you add more flowers. That really lets players get the hang of the game mechanic.

Anyways, big fan of the html5 stuff... my current project is ( __WARNING __CPU killer<http://chesser.ca/jsSprite/12-glorious.php>) it's all up on github if anyone wants to look at the code <https://github.com/AlexChesser/jsSprite>

<comment><USER3> Oh hey!

Glad to run into your progress. Hope the game does go well.

<comment><USER2> Thanks Simon! (to anyone onlooking, Simon has answered every one of the questions I posted on Stack Overflow with respect to getting this rolling)

</comment></comment></comment><comment><AUTHOR> Hi,

I threw this game together last weekend, and have struggled with the UI for the remainer of this week (clearly not my primary competency :) ). The game is 100% HTML/JS, where the only HTML5-feature used is really the "font-face" functionality. Technically it is entirely based on jquery and some of its plug-ins. Would love all kinds of comments!

<comment><USER4> This game is awesome. I gave up on a similar HTML/JS game I was making because I could not think of the gameplay/goal/prize: <https://zetabee.com/games/bee> \- I love your 'find pattern' goal. I think with these kind of puzzle games, the hardest part is coming up with a good effort/reward system that makes gameplay fun instead of tedious and you did an awesome job with Garden Madness!

<comment><AUTHOR> Thanks Chime! Looking at "Bee in the garden" right now thinking it looks awesome! What have you used to build it?

<comment><USER4> Mostly <http://raphaeljs.com/> and jQuery.

</comment></comment></comment></comment><comment><USER5> More broadly, dealing with HTML5, how do you protect your source code/ intellectual property? Seems like it is all there in the javascript. I know flash can be cracked but it does seem like there is a defense layer.

<comment><AUTHOR> There is not protection at all, it is all open source, literally. You can add fancy stuff on the server side, which of course will be a well kept secret, but currently it is all client side and out in the open. I am not that worried though, this game is not rocket science if you were to re-create it ...

</comment></comment><comment><USER6> Very nice... a few suggestions:

\- When you click a constellation and win a chance, unless you match a group of 4+ on the same move that chance is used up immediately. Perhaps it would be more intuitive to have it as a free move?

\- For chances remaining, when it shows 1 and you use it up it's game over. I was expecting that when you use your last one up, you have 0 chances remaining after which missing a group of 4+ is game over.

\- As others have mentioned, sound effects would do wonders... increasing in pitch as the chain number increases, just like Beflowered, er... Bejeweled does it. :)

\- Consider adding a timed mode to increase the pace and excitement.

Again, great work. It looks and plays incredibly well!

<comment><AUTHOR> Hey, thanks alot for your feedback and your kind words! \- Did not consider that, but when you mention it, it sounds more intuitive the way you propose it. Will be a part of the next version. \- You are correct, and I will add this as well. \- Sound effects coming right up! \- Additional game modes are high up on my todo list.

</comment></comment><comment><USER7> Once you found your way in, it's really addictive. However, if you could make the introduction a little easier to grasp, more people would give it a try.

<comment><AUTHOR> Absolutely, thanks for the tip! Making things dead-on easy is my top priority at the moment, so I will definitly look into this

</comment></comment><comment><USER8> I tried and I liked the UI and the game seems responsive...

However - I am really lost as to how to play. I tried finding 4 of the same color more, I had none on the board.

I clicked to re-arrange and stuff happened, but I did not follow what was doing as flowers flashed away in front of me....

Maybe a better explanation or tutorial...

Or maybe I am just dense...

<comment><AUTHOR> Hi, I will surely work on making the game more self-explainatory, and I will add better "in-your-face" descriptions. As it stands, I do agree that things might be confusing for first-time players. Thanks for the feedback!

</comment></comment><comment><USER9> I'm not much of a game player these days, but I have to say that I played this for a while. You did a great job with everything. I would say the instructions need to be a little more clear to make it easier to start and it would be cool to see scores for everyone.

<comment><AUTHOR> Many thanks! I will definitely work hard on getting the instructions on-parm as it seems to be common sentiment that the game is lacking in this regard (and I do agree...) :)

Global highscores are also high up on the todo list.

</comment></comment><comment><AUTHOR> UPDATE: Garden Madness now comes with sound! (which you of course can turn off if it gets on you nerve :) )

</comment><comment><USER10> Very cool, nice to see a game that is both HTML5 and fun to play. :)

</comment><comment><USER11> I like it! I got the highest scoring click of "all time" :)

<comment><AUTHOR> Good job, even though all highscores are local, not global. :) Should probably mention that somewhere.

Speaking of global highscores in a JavaScript/HTML context: Anyone knows how to create a set-up that prevents cheating? The only approach I've seen that seems viable is to register all events and verify the order and validity of these server-side, which of course is a bit cumbersome.

</comment></comment><comment><USER12> Really nice - wonder how it converts / runs as a phone app

<comment><AUTHOR> Excellent question, I have not had the time to test it on my iPod Touch yet, so I am basically keeping my fingers crossed that it still runs ok. Has anyone tried loading this up on Android/IOS?

<comment><USER13> You might want to look at a project such as PhoneGap.

I've been using them for a work related app on iOS, and it's incredibly useful and easy to use.

<comment><AUTHOR> Excellent suggestion, will do!</comment></comment></comment></comment>


Nick Bilton Keynote O'Reilly Tools of Change 2009 - <AUTHOR> http://www.metaprinter.com/2009/03/nick-bilton-keynote-oreilly-tools-of-change-2009/

<comment><USER2> 1876 the telephone - people will never leave their home again 1877 the Phonograph - has eclipsed the telephone, people will never leave their home again.

nick always gives a great presentation.</comment>


Google Related - <AUTHOR> http://googlesystem.blogspot.com/2011/07/google-related.html

<comment><USER2> Wow, interesting to know how much Google knows about me.</comment>


Show HN: Apps ranked by valuation - <AUTHOR> https://sensortower.com/ios/leaderboard/estimated-app-worth/all-categories

<comment><USER2> How are these valuations calculated?

For example, Instagram has an estimated value of ~$4.6 Billion, but it's actual value (based on purchase by FB) is ~$1 Billion. The page doesn't provide a clear link on how they estimated the valuations, either...

Edit: If you click on one of them, then mouse-over the valuation on that page, if offers the following explanation:

"To calculate App Worth, we take into account many factors and metrics:

\- User Estimates

\- User Activity

\- International Reach

\- Revenue Estimates

\- Sensor Tower Secret Sauce™"

<comment><USER3> Not sure why this is secret. A formula would be useful, but I guess this is just a fun estimate.

<comment><AUTHOR> Part of the reason for that is that I didn't want people gaming the algorithm. The things it looks at are user numbers, revenue estimates (very good here~) and internationalization when computing the worth.

<comment><USER4> Some of the valuations raise a bit of an eyebrow - e.g. BatteryHD valued at nearly $41M.

* In the case of apps that are native versions of web services (e.g. Flickr, Twitter) it's impossible to separate the value of the app from the service, so is your valuation of the whole service?

* How do you factor in possible future growth, based on potential size of market, current market saturation, and possible revenue streams? It seems like they would be very difficult to automate.

So the valuation of the app-maker is probably more interesting than the value of the app itself. A company that has made one very successful app is more likely to make other successful apps, because of branding and experience.

</comment></comment></comment></comment><comment><USER5> Accuracy aside, this is interesting.

The thing that always sands out to me in any "thing - value" list always how little correlation there is between hard/complicated things and value.

Whatsapp vs Viber. Kindle vs Bible. Waze/Google maps vs Urban Spoon/Yelp. Creating an awesome bible app seems incredibly doable.

<comment><AUTHOR> Yep, creating an awesome Bible app is doable. Getting people to download and use it, that's the hard part!

</comment></comment><comment><USER6> Apparently there's a lot more money in Bible apps than I had imagined.

If this ordering is close to being accurate, it's a wonderful resource to reflect on to understand what consumers truly care about.

<comment><AUTHOR> We've also got an ordering based on number of ratings: [https://sensortower.com/ios/leaderboard/estimated-app- worth/...](https://sensortower.com/ios/leaderboard/estimated-app-worth/all- categories)

With the Bible app, I was surprised too when it showed up -- but the app has over 30 million users. It's quite bigger than a lot of funded social networks, it is just a matter of monetizing or engaging the users properly. Religion is a big market!

<comment><USER6> Thanks for this resource!

</comment></comment></comment><comment><USER7> I'm a valuer/appraiser by trade and would be interested to know how you're making calculations. Direct cap or irr (DCF)? A dollar amount multiplied per estimated user?

</comment><comment><USER8> Dunno how accurate this is for the biggest and free apps, but I own a medium size paid app and it seems reasonable. The search/keyword graphs they have are interesting too, haven't seen that data before.

</comment><comment><USER9> I wouldn't put any games in the top ten (or even top 50). I don't see Candy Crush or Clash of Clans being around six months from now, so I don't see how it could be worth anywhere near $1.36B...

<comment><AUTHOR> Well, given that Clash of Clans has been around and in the top 3~ grossing consistently for the last year, and Candy Crush has been at #1 for a year and a half, and neither show any substantial signs of slowing down and are improving on game mechanics and monetization strategies I would take your wager. These apps are very international and in the App Store terms, a year is quite a long time.

<comment><USER10> I'm with you on Candy Crush (my family has numerous addicts) but I'm not sure it's worth so much more than Angry Birds.

Angry Birds also makes money offline (soft toys etc) but presumably that's not covered in your table....

</comment></comment></comment><comment> k-mcgrady Not exactly sure how the valuations are calculated but they don't seem too accurate. I looked at my own apps and some that should have appeared didn't, others that shouldn't have appeared did.

</comment><comment><USER11> Looks great! One curious thing I'd be interested to see is the sum of the values of all the apps and how it compares with Apple's estimates.

</comment><comment><USER12> So:

\- Pandora's app is worth $1.7bn

\- Google's Search app is only worth $0.7bn

Riiiiight...

<comment><USER5> If pandora didn't have the pandora app, it would be out of business. If google didn't have the google search app.. it would probably not be noticeable on its balance sheets.

<comment><USER12> Pandora existed before it had an app so I'm not sure it would be out of business. A significant proportion of its business may go through the app but that's not the same thing.

Google is a vastly bigger scale business though so I'm surprised such a small percentage of its profit is attributed to the app. Especially as they are pushing Google Now.

In general, though, I'm not sure the attribution of profits to apps is consistent for multi-platform businesses.

</comment></comment></comment><comment><USER13> I will happily sell my apps for the price listed. Who should I contact for my check? :)

</comment><comment><USER14> They seem to have mixed up Sweden with Slovakia. Funny.</comment>


Archive.is domain hijacked? - <AUTHOR> http://archive.is <comment><AUTHOR> I just get a blank page with the following message:

>Привет, и рад Вас видеть на этом лендинге! К сожалению, этот домен занял я, поскольку администраторы archive.is не поменяли записи при импорте\экспорте записей с CloudFlare. К сожалению (снова, sic!) так бывает. От слабоумия, или от того, что времени нет, не знаем... Вопрос к администратору - хочешь вернуть домен? Напиши на email@example.com

which google translate translates to:

>Hello, and glad to see you on this landing! Unfortunately, this domain was occupied by me, since the administrators of archive.is did not change records when importing / exporting records from CloudFlare. Unfortunately (again, sic!) It happens. From dementia, or from the fact that there is no time, we do not know ... Question to the administrator - do you want to return the domain? Write to firstname.lastname@example.com

According to wayback machine, the site looked normal on Sep 23rd: [https://web.archive.org/web/20180923055338/http://www.archiv...](https://web.archive.org/web/20180923055338/http://www.archive.is/)</comment>


JavaScript development is not fun for me anymore - <AUTHOR> https://medium.com/@paulvm/javascript-development-is-not-fun-for-me-anymore-ac4e9d7b89a3 <comment><USER2> I don't think there's that big a problem with how many front-end frameworks there are, and the pace of development. I think the problem is people who feel they have to use the latest and greatest feature and they have to know all the frameworks.

At my company we picked a stack and stuck with it. That happened to be React and Redux. I hear Angular 2 and Vue are really great frameworks but I feel under no pressure to really investigate them because we're doing fine as it is.

Two years later and we've barely changed aside from some package versions. We've got a very stable front-end with high code quality and component reuse.

You don't have to listen to the hive-mind. Frameworks don't rust.

<comment><USER3> > Frameworks don't rust.

Ah, the optimism of youth. Frameworks don't rust if you don't mind sticking with the security bugs of 10-year-old kernels. If you need to upgrade your OS, you need to upgrade your programming languages, which means you need to upgrade your frameworks.

Everything rusts pretty quickly. Maybe you don't need the new features, but you definitely need the new bugfixes.

<comment><USER4> The problem is that everybody publishes bugfixes alongside new features. This practice should be stopped, because it leads to dependency hell.

<comment><USER5> Open-source maintainers should _totally_ leverage this opportunity to make their projects sustainable. _Sell your backports. Enterprises want them._

<comment><USER6> That actually sounds like an interesting business model.

What form would the transaction take?

<comment><USER4> Yes, and how would maintainers know which versions of their software are actually still used?

<comment><USER7> You mark releases as "Stable and supported" and have corporations subscribe against releases. If you are subscribed to a release, you get bug fixes for that release. If someone does not have a subscription to a release, it does not get updated, and if there is no current subscription for that release, you don't accept new ones.

You always allow people to move forward their subscriptions, but never backwards. You provide migration paths for each supported release.

People will pay for it.

</comment></comment></comment></comment></comment></comment></comment><comment><USER8> But JS dev has never been fun.

Web dev is fun because the browser is a freaking awesome plateform.

However, it is _despite_ of JS.

There's not a single characteristic of this language that makes it better than any other mainstream high level language out there. We use it because we have no reasonable alternative on the browser. It has always been a pain to use, requiring:

\- avoiding part of the language that is badly designed to escape traps.

\- recreating basic features that you take for granted in any other tech like isolation, namespacing, primitive stlib features, etc.

\- fight with the various implementations to find some code that will work for most of your customers.

\- use tooling to compensate any weakness you can. Remember the most popular projects in JS (coffee, tsx, jsx, babel, webpack, etc) are mostly projects allowing you... to avoid writing JS.

The fact that the community is now shooting itself in the foot by providing so many incompatible, badly documented and breaking-compat-all-the-time tools is just icing on the rotten cake.

P.S: since this comment is getting upvotes, I will say that having used in prod vanilla, jquery, react, angular and Vue, I will stick with Vue for the next years. I'm done. My quest is over. It takes 3 hours of reading to be productive with it. It requires no tooling and yet can be used with existing tooling. It's fast. It's well documented. I can now focus on writing software again.

<comment><USER9> Async is super simple in JS. Yes callback hell can be an issue, and it may be ugly, but there's many a time where I wished for it in Python and ended writing a script in NodeJS.

<comment><USER10> Python has asynchronous coroutines (the async/await thing) so you don't really need to do callbacks as far as I know. I personally find that syntax much easier to follow than callbacks.

</comment></comment></comment><comment><USER11> React + (early flux and later mobx) made web development fun again for me. I was burned out at the end of the jquery era with all the different homemade structures and the limitations of browsers.

Then I came back to React and babel/gulp (later webpack). Suddently there was structure in the front end that was easy to get into a project and contribute. Building components just felt right. Also js was almost a modern language now and I could use it even if the browsers did not actually support it yet.

<comment><USER12> I feel the same way... web development was hard, until I've learned about es6/babel, webpack, redux and react (I'm using morphdom as react replacement, but idea is the same). Now web dev is easy and fun. I have state, components, events and routes. That's it. Update the state and stay calm.

The idea to concisely manage the state together with dom diffing, are my personal favorite game changers.

<comment><USER13> Can you provide some guidance/links to a backend Java developer who wants to learn & use a quality long-term, front-end tech stack? Is there a kickstart example project for your preferred stack? Note that I prefer to avoid nodeJS for any back-end production use but am ok with it as part of the dev toolchain, if required. Thank you.

<comment><USER11> I would say just start with the React tutorial and use the react-create-app (uses webpack etc in the background and is a npm package) that they use in it. Then after the tutorial I would go into the docs and read through them and maybe test some.

After that I would pick the state management tool I want. Either Redux or Mobx as both are popular and have their advantages and disadvantages. I think it is worth going through both their official tutorials as they are pretty good.

[https://facebook.github.io/react/tutorial/tutorial.html](https://facebook.github.io/react/tutorial/tutorial.html)

[http://redux.js.org](http://redux.js.org)

[https://mobx.js.org](https://mobx.js.org)

There are of course tons of videos but I think the official tutorials are a great start and using react-create-app instead of trying to dig into webpack and all that is really good at the beginning.

</comment></comment></comment></comment><comment><USER14> Just pick one and stick with it. There's some serious FOMO going on in the JavaScript community. When you read articles talking about all the great benefits they see from switching frameworks, _what you don 't see are the gains they'd have if they just rewrote everything in the same language/framework, taking advantage of the increased experience since the original write._

</comment><comment><USER15> 14 year .NET veteran here. For me Javascript (actually Typescript) using Vue as the front-end reinvigorated my joy of creating web applications again.

<comment><USER8> Vue is the only glimmer of hope a JS project gave me for the last 5 years.

I actually sent a donation the very first afternoon I started to read their doc, because I decided that even if I would not end up using it, I wanted the author to be supported for just existing in the universe.

Of course I ended up using it anyway.

<comment><USER16> Out of curiosity, what did Vue do for you that React didn't? I've been writing React for three years now and I can't find a compelling reason to even try Vue out.

<comment><USER8> Nothing.

For me the selling points of Vue are:

\- You don't need tooling to use it. You can use tooling, but you don't need any. It makes it freaking easy and fast to start a small project with Vue and increment on that. Webpack can wait.

\- Vue doesn't force components on you. Since most of my "widgets" are not reusable anyway, I really loves this. I write components only when I need to, usually a dozen per projects.

\- You don't have to pass state around using callbacks and props to make it works without a store. State is just an easy mutation away. I'm not facebook, most of my projects don't need a flux pattern, and having Russian dolls data passing shenanigans just so I can update my UI is a pain.

\- Vue documentation is stellar. It's wonderful. Like a walk in the parc with a friend.

\- Vue is so easy to start with. React took me a while to click. Vue took me 20 minutes. It's incredibly easy to train new people coming to your project. And as a professional trainer, the difference with students is just night and day.

\- Vue is very, very efficient. The lib is so small. But yet it's faster than react.

\- Vue has a lot of helpers that you can tell have been made by a pragmatic author. onclic.prevent and v-on:customevents are poetry to me.

\- After after hours and hours of react, I still have to look at the docs. I still have surprises. With Vue, the surprises stopped after day 3.

\- I hate JSX. Matter of taste of course. I like the Vue template language, but Vue can optionally use JSX if you prefer it.

\- Some very vocal people in the React community are dishonest. They will tell you you can use react without tooling or JSX because technically you could. But technically is not pragmatically. Nobody would. And you are on your own if you try. I hate fan boyism. Compare to Vue: the author even has a comparative page of most frameworks with Vue. He co-wrote the react part with react authors to get it fair. That, I like.

</comment></comment></comment></comment><comment><USER17> I totally agree with the sentiment. While others tend to use SPAs with their complex build system and lifecycle for everything, I follow principles of ROCA [1]. I don't understand why people think it is better and faster to make complex clients that include logic, that has to be verified on the server anyway. Everything I saw / see in the enterprise world is reinvented for client-side development again.

[1] [http://roca-style.org/](http://roca-style.org/)

</comment><comment><USER18> The last time I've really touched JavaScript is about a year ago, I'm just working with Python these days. Thinking back, I had 2/3 newsletters about JavaScript and whenever I've read them there was a headline "why X is better than Y", "Y has no chance against Z" "Good old X is better than Z,Y".

I was always feeling, that I'm missing out on something and that I needed to learn new things. Switching to python actually made writing code enjoyable again.

</comment><comment><USER19> I teach a course at upenn on intro to javascript. Perhaps the most useful advice I give to my students is that often the simplest tools will get the job done i.e. you don't need React, Redux frontend stack because for most cases jquery will get the job done much quicker. Only worry about the frontend libraries when you feel it's getting out of hand, otherwise, the simple, straightforward tools will suffice.

<comment><USER20> I haven't coded much JS since ES5. With the improvements to vanilla JS, are there still a lot of things that jQuery provides that vanilla JS does not?

<comment><USER19> Yeah vanilla js still is a pain to access the Dom with.

</comment></comment></comment><comment><USER21> The desire to constantly switch JS frameworks is really confusing. I find each one different, exciting in their own way and fun to learn. However, and this is a big however, none of them radically change the work you'll create, so I'm happy with React, and not interested in learning just to learn. Maybe in a year or two, I'll try Vue, it won't be too hard to pick up.

If you're at BigCo making internal apps, each one is basically dressing on a way to make various interactive UI states. How you get there is no big deal. How the data flows is no big deal. What test runner you use is no big deal.

As a JS dev, my passion is to learn completely non-JS related things. Cryptography, Blockchain, CS Fundamentals I missed. These are much more interesting than the churn.

</comment><comment><USER22> Speaking as someone who has seen the ebb and flow of frameworks galore on the front-end and back-end, I've found many devs swing back and forth between love and loathing. It's just a natural evolution of how we use tools, and quite often the over/under application of those for the problems we're trying to solve with them.

We've never had more options available to all of us to build complex systems, applications and services using highly-targeted tools. The new-framework-a-day pace at which these become available to us is fine, but honestly doesn't move the needle for most of us.

A former leader of mine once said: you build things with tools, not popularity contests. I've found keeping such a perspective makes my stress level manageable.

</comment><comment><USER23> > After I was done with the front-end of a project, I hated that I had to do > the back-end. I also was not good at it.

After many, many years of tutoring students in a variety of subjects, there is definitely a connection between the last sentence and the first. People who work hard to get good at a particular subject often find themselves enjoying it a lot more. But humans don't care much for delayed gratification. If we have work that we could be doing that we enjoy more than some other work, than the hated work gets put off. Often indefinitely, as no skill in it ever gets developed, the more it is put off.

</comment><comment><USER24> I think this is a good description of how front-end development has become a "tool zoo", where new versions of libraries and frameworks are often radically different, and new libraries/frameworks keep popping up. I compare this to Python, where most of the time learning a new library will keep paying off for years and years. It makes front-end development an expensive (educationally) place to work, and the maintenance costs of the code are substantial.

</comment><comment><USER25> > How to use styled-components to make JavaScript in React do what CSS can do > on it's own.

Stopped reading right there. CSS-in-JS is one of the main reasons I'm even using React to begin with.

</comment><comment><USER26> Spend your time learning something that isn't subject to fads. In five or ten years, React will be a distant memory. Just like all the PHP frameworks are now.

Focus on getting good at the web platform standards. I personally jump at any opportunity to learn new web platform APIs, graphics techniques, design patterns, data structures, and different business domains, and stay away from technologies that are fad-driven.

Get good at a few basic tools and focus on application development. It's not about the code its what we make with the code.

</comment><comment><USER27> I hate JavaScript with a passion, but 95% of that is fixed with TypeScript. But the thing that TypeScript can't fix isn't really related to JavaScript, but rather everything around it:

1) Build systems suck. Millions of plugins and adapters, opaque json configurations, silent errors, finicky and difficult optimizers, source maps upon source maps, shims everywhere, etc.

2) Browsers have unpredictable noncompliance with standards, HTML doesn't work well for user interfaces, CSS is obtuse, etc.

</comment><comment><USER28> I started to feel the same way as the author when 2016 rolled around. I found myself getting caught up in the paranoia of using the latest, greatest, most popular (i.e. supported) framework. Teammates would come to me with a bunch of proposals about how to use X over Y. We questioned continued use of Angular 1.x and had similar negative experiences with the build processes around the latest javascript frameworks. It really had gotten a bit out of hand considering our scope.

I found the light at the end of the tunnel with Riotjs. It is close enough to the bare-metal JS runtime to keep you sharp in that regard, but also provides a lot of utility around building components without tying your hands in any particular way. For someone who is trying to build the best UX experience possible, I feel like riot or even vanilla JS provide a much better experience for expressing yourself.

Front-end frameworks seem to me to be just a way to systemize the UX/UI problem into a thing that back-end engineers can reason with. Staring down a blank HTML/JS/CSS document without any constraints imposed on you can be a very daunting task until you truly get a feel for it. I strongly believe that one can be VERY productive on even the most complex web project without use of any frameworks, assuming they have the correct "artistic" mindset and the ability to balance that with systemizing the problem. My perspective is that the web is 3 languages (HTML/CSS/JS) and they need to be treated as equals. Any time you bring in a framework that does not consider all 3 with the same priority, I strongly feel like you are losing something.

Since switching to riot/vanilla js, I have spent WAY more time thinking about how I want the UX to be than how I can force it into the various boxes some framework wants me to. In the Angular world, things like "it would be nice if that checkbox turned into a DDL when checked" would result in sweaty palms and much googling for phrases like "dynamic element swap directive" and an entire afternoon wasted. When you are used to working with DOM directly on a daily basis, this is a hilariously trivial activity requiring about 2 seconds of deep attention.

</comment><comment><USER29> Despite its flaws I tend to stick with Backbone whenever I need to do anything sufficiently complex on the frontend, and jQuery if it's any simpler. When writing software for money I've always found it pays to take a conservative approach.

<comment><USER30> I wouldn't jump too far ahead when writing software for money, it's always better to use something you know will work and have enough familiarity with to adjust around its deficiencies.

But I think Angular 2, React and Vue are all getting to that point if not there already.

</comment></comment><comment><USER31> It sounds like he doesn't dislike JS, he dislikes what web development has become.

I dislike build tools and all the little doo-dads that we __have __to have now. Like, sometimes I just want to write some CSS and launch it with `npm start`

<comment><USER32> Well create an index.html, inline a style tag in said file, write some CSS, npm init, npm install http-server -g, update package.json to with this script "start": "http-server", and profit.

Fear not, we have the technology.

</comment></comment><comment><USER33> My biggest complaint about Javascript development is the config... OMG the config. So many modules, so many dependencies, so many build steps, so much half-baked documentation, so much assuming that you already know X, Y, and Z.

</comment><comment><USER34> To put a finer point on his argument; I'm working on an Angular project at the moment. Every time I refresh the page I have to wait 10 seconds before I see any of my changes while Angular compiles everything. I calculated that, given the number of times I have to refresh to test my changes, all of those 10 second compilations is costing my client tens of thousands of dollars every year in wasted productivity. So I can't help but wonder how Angular and their ilk are better?

</comment><comment><USER35> $ ls node_modules | wc -l => 872 * Starts crying _

</comment><comment><USER36> It's been fun again since I stopped worrying about keeping up with framework churn and all the tooling. I still feel bad when people ask what framework we use and I can rattle off a list of trendy new stuff but I quickly remind myself how asinine that is and go back to making perfectly fine, successful- in-production JS apps with stable boring things like ES5 and Backbone.

</comment><comment><USER37> > So that's why I'm now learning to be a Web Animator and UX Designer.

Has anyone played around with the Web Animations API?

I noticed that Chromium now lets you use elem.animate to animate SVG elements-- even properties like "width" which aren't technically presentation attributes in the 1.1 spec.

Anyway, it's a very handy interface and easy to play around with inside about:blank to prototype things.

</comment><comment><USER38> Well, that's what happens when you move the problems from the server to the browser (routing, dynamic data, auth, etc). instead of focusing only on UI you are working on a complete application.

I like making SPAs, but there is really no need to do that. In many cases making an SPA is not even desirable.

</comment><comment><USER39> Using Typescript with Angular2 + RXJS is like my second wind and a breathe of fresh air. It's like web development is "real" software development now.

</comment><comment><USER40> > [Front-end is] looking more and more like the back-end

This rings true to me. It's also partially why I don't really mind front-end development like I used to.

</comment><comment><USER41> I must admit having a hard time relating to all the complaints over js churn and the new world of...compiling code. I hated website dev in the past, hated using jQuery, hated being driven insane by the css cascade, hated wasting all my time on arbitrary and stupid browser incompatibility bugs with magic arcane solutions.

I develop apps---not traditional websites---so I know this colors my experience. But every single tech change that I've made the past 4 years has been motivated by a real need. (Of course this assumes I have control over the tech: I'm grateful that I've only been forced to work on one Angular project for work!)

I started using React in December 2013 after a shootout of the competing view libraries at the time because I didn't like having to be Sherlock Holmes to figure out how to change someone else's (or my own!) wild jQuery code, and I always inarticulately felt like I was fighting against a natural flow when using the old MVC frameworks. I now haven't churned my basic framework for almost _4 years_. And don't expect to for many more! (I know that to an extent I got lucky: it's easy to forget now how much shit I got at the time for using dumb React lol compared to Angular). Ember is fascinating, I'm glad Preact, etc is around as a backup...but churning would solve no problem for me, and most jobs I'd get (for years now) require React, so why worry about changing?

I've been a redux user for over _2 years_ now. I eagerly switched over the codebase I was working on because it solved a need I had: getting rid of a bug-prone, undocumented state solution of my own design which everyone else had to figure out for themselves. I expect I will switch out redux one of these years. But haven't seen anything to motivate it yet. Mobx-state-tree is very interesting, but until I see the benefits are worth the switch, why churn?

I did really hate having to worry about babel, webpack, etc since it distracted from writing actual product code, though ES6 was just so obviously better than old JS that it was worth it. But now create-react-app and its siblings make the dev environment a matter of typing a single command. Contrary to this article, it points out errors that could easily have gone undetected in the the old world of wild web dev. No churn here. CRA all the way. Until I run into a need for something new.

Styling solutions are something I have actually churned. But because I knew I wasn't committing, all css-in-js library code I write is in two or three "ui library" files. The app code itself only uses a jsx prop interface. So swapping these libraries on a mature app takes an afternoon at best. Though for the first time I now expect that I'll stick with Glamorous. I expect I'm going to stop churning here because I'm aware of no problem I personally have that Glamorous does not solve, unlike previous css-in-js libraries.

I don't know, this guy's rant just put me in the mood for ranting lol. Anyway, I'm glad this guy found his real interest now might be as an animator and UX designer and I wish him the best! Those are important contributions too, possibly more important.

</comment><comment><USER42> He wasn't a programmer since the beginning. He was a designer.

</comment><comment><USER23> I think Framework-itis is a result of front-end developers—who are often junior developers who may not even have CS degrees—inculcating the false message that they are not "real" developers. As an industry, we have treated front-end development work as entry-level, occasionally even frivolous work, as it grew organically out of the left-over work that systems developers gave to the designers.

Developing a framework doesn't look very much like doing front-end work; frameworks are generic, planned, and built from scratch, whereas the typical front-end developer is used to making highly-specific, ad-hoc changes to existing code (either because they've come in on a project started as a proof- of-concept by more senior developers, or they've used a boilerplate generating tool). Being more like so-called "real" software development, only "real" developers should be allowed to work on something ostensibly so important and complex as a "framework".

The front-end developer has been indoctrinated into believing she (and it's very often a she, 'cuz design work is women's work, amiright?) has no business writing code, and that the code she does write is woefully "WRONG, WRONG, you're doing it wrong! What are you even trying to do?" by the karma-craving, bottom-feeders of StackOverflow. To avoid further public shaming—lest there be some hidden defects their inexperienced eyes cannot detect, no matter how trivial the bit of code may be—they avoid the actual act of writing code as much as possible and spend an inordinate amount of time searching for packages that may be imported from the gods. Thus left-pad, and the ensuing post-hoc rationalization in that debacle's aftermath that such trivial micro-packages are somehow a _good_ development practice.

I don't think there are a uniquely numerous quantity of framework projects in front-end land. Systems developers make custom tools all the time. But systems developers don't have a general fear, uncertainty, and doubt about their own work sewn into them, so it's more common for systems developers to jump into writing their own code than looking for pre-existing tools in whatever they might deem as trivial. Instead, I think a plethora of front-end tools reach a unique tipping-point level of popularity giving the _perception_ of many more tools total, because of a general fear of falling behind. The front-end developer sees themselves as having no business criticizing their "betters" and must therefor accept what is handed down to them without question. If the front-end developer cannot prove they are a good little worker bee by keeping pace with any and all frameworks their benevolent employer or more-senior, more-"real" coworkers may spring on them, they risk having to go back to working as a barista.

Something to think about while replying to a seemingly "simple" questions.

<comment><USER43> You're drawing from quite a lot of assumptions. Consider that until recently, "front-end" work was done mostly on the server.

<comment><USER23> I think I know what the history of web dev for the last 20 years has been, considering I've lived and worked through it. Your comment doesn't change anything. There has always been a client-side component of web apps. While in modern times it has become more richly interactive and complex, it's pretty clear the people who work on it have not received a similar upgrade in respect.

</comment></comment></comment><comment><USER44> _> Plus, now I have to learn what Redux is, and how Vue is the next best thing that happened since Angular 2.0. How to use styled-components to make JavaScript in React do what CSS can do on it's own._

I'm glad I get to call the shots where I work, and I've steered my team clear of all of this stuff. If you have a deep knowledge of the core technologies -- HTML, JS, and CSS -- you can build a great front end with a reasonable amount of time and effort. If something breaks, it's likely going to be our own code, and much easier to diagnose and fix.

<comment><USER45> To me this kind of thinking sounds so strange.

A framework is (like it's namesake) a frame that you can build around, it's a tool that enforces restrictions on you by design. Obviously there is some overhead to learning that framework, but the idea is that the framework is built by someone who spends their day-job building the framework. They are going to do a better job of designing a framework than you will in most cases.

Yes, you _can_ build something great without them, but for any moderately sized project, you will end up re-inventing a set of rules and restrictions to apply to your own internal code. You will in-essence create your own framework.

And that's fine, I'm almost positive that your "framework" will do some things very well, probably better than most of the competition, but you need to ask yourself what your main goal is. Are you setting out to build a framework? And/Or are you trying to build a product?

If the answer is that you only want a working product, time spent on building your own framework is time wasted, as in my experience you will spend significantly more time writing your own from scratch than you will ever learning one. Doubly so if that framework isn't designed to be reusable at least in your organization. Not to mention the overhead of having all new devs have to learn it anyway.

However if the answer is that you are setting out to build your own framework (because the current ones have a limitation that you can't deal with, or some problem that you need to solve yourself), then by all means go for it! But that can't be given as "general advice" as for many people (I'd guess most people), as they don't have those same goals as you do.

Frameworks are a tool, and telling people to forgo "pre-made" tools and create them yourself is going to be the wrong advice in most cases. (but not all cases!)

<comment><USER44> _> They are going to do a better job of designing a framework than you will in most cases._

My own framework will do exactly what I need. No more, and no less. It will only solve problems that I actually have, not ones that I don't. My framework will suit _my_ needs better than theirs will, each and every single time.

 _> If the answer is that you only want a working product, time spent on building your own framework is time wasted, as in my experience you will spend significantly more time writing your own from scratch than you will ever learning one. _

Time is not the main factor. I would rather have something lightweight that does exactly what I want, and only what I want, than some sort of generic one- size-fits-all thing. I don't want to deal with upgrades that are not backward- compatible. I don't want to spend days debugging someone else's to figure out what I did wrong.

 _> Frameworks are a tool, and telling people to forgo "pre-made" tools and create them yourself is going to be the wrong advice in most cases._

I'm not telling anyone to do anything. I'm only sharing my own personal views on the subject of the article. For a lot of people, I don't doubt that React or Angular is the best course, for a variety of possible reasons.

It's obvious to me that you and I approach the craft of software development from two entirely different angles. It's obvious that you perceive a great deal of value in these framework, so your best bet is to continue using them.

<comment><USER45> If time isn't the main factor, then by all means you have the right idea! But I've never really been in a situation where I can afford the time and manpower to do everything myself, so my view is skewed by that.

And I do apologise for going off on the tangent there about not telling people to do X or Y. I got a little wrapped up in it and that comment was less targeted at you and more at other people I see advocating for it.

Also, I wouldn't say I perceive a great deal of value in these frameworks, just that I use them like tools where they make sense. Across our codebase we have 2 react applications (one with webpack, one with just script tags), one node.js application without any real framework, and one jquery+vanilla-js codebase. We use the frameworks where they make sense, and don't where they don't. And while i'm absolutely certain that a purpose-built framework would serve us better in many areas than something like react will, I don't have confidence in my skills to create something that will stand the test of time. I know what I don't know, and I'm pretty sure that I made the right choice externalizing that work on to someone who has a team of people working just on that aspect.

I try to spend my time where it's best used, and in the vast majority of cases I've found that it's best spent working directly on my problem domain, and not on aspects like state management, rendering performance, cross-platform compatibility issues, and more where it's not needed.

</comment></comment></comment></comment><comment><USER46> Please try TypeScript. It's the only tech I will actively promote as 'not a fad' but a very useful thing. So useful, I stopped writing JS the first day I tried TS.

For anyone with a background in classical software, it makes JS 'feel more real'.

I can't imagine writing more than 50 lines of JS anymore.

</comment><comment><USER47> JS moving in the direction of being compiled, statically typed, and adding lots of boilerplate for various reasons. When I started writing JS, it was partially to get away from these things in the .NET world. So, to be honest I don't enjoy these changes in isolation, but I understand why they are happening.

I like that we're starting to think in a more systematic way about how to organize applications, and I think that bigger codebases and teams probably benefit from using static types. But god, sometimes when you open up these codebases they sometimes hardly look like JS anymore. Not to mention the tooling and build stuff, which still have a lot of maturing to do.</comment>


We're not leaving this bar til we've got such a great idea that I can't sack you - <AUTHOR> https://medium.com/storythings-ltd/we-re-not-leaving-this-bar-until-we-ve-come-up-with-such-a-great-idea-that-i-can-t-sack-you-b12ddfd53fa8#.relt72qwc <comment><USER2> The video of Foinavon winning he links ([https://www.youtube.com/watch?v=pZ_JCOgHE2U](https://www.youtube.com/watch?v=pZ_JCOgHE2U)) was surprisingly thrilling. Almost every other horse goes down and Foinavon leaps ahead - but a couple horses nearly catch up by the end of the race.

Definitely an example of 44th mover advantage.

<comment><USER3> We call that a Bradbury in Australia ;) [http://youtu.be/tYUjmEH9NNk](http://youtu.be/tYUjmEH9NNk)

Not quite as thrilling to watch, but amusing all the same.

</comment></comment><comment><USER4> The last couple of paragraphs were such fertile ground for being expanded upon. This was a great piece, and I really hope we get to hear that piece as well.

</comment><comment><USER5> I really like this person's career path, as it should be an example to everyone who thinks they need external validation to do a certain profession.</comment>


WebSimpleDB API - <AUTHOR> http://www.w3.org/TR/WebSimpleDB/ <comment><USER2> I'm all in favor of simplicity, but there isn't much that seems simple about this proposal.</comment>


Bathroom usability. - <AUTHOR> http://davidkyoo.posterous.com/bathroom-usability

<comment><USER2> How a bathroom usability post got written without a reference to three seashells, I'll never know.

</comment><comment><USER3> Bathrooms are rarely designed with OCD sufferers in mind.</comment>