HN user

bahmutov

56 karma
Posts11
Comments34
View on HN

Wow, someone has submitted Cypress.io here - probably because we just crossed 25k stars on GitHub.

We at Cypress do read these comments, and we definitely understand both the positive and negative opinions. If you have never tried Cypress yourself - take a look at the first test page https://on.cypress.io/writing-your-first-test

Try it yourself, you might like the syntax and the developer experience. And if not - no worries, there are TestCafe, Puppeteer, Playwright, Selenium, Webdriver that might work better for you.

That's why I recommend using PouchDB to work with whatever API is available. Storage limits are harder to work around, but if your HTML snapshot weights more than 50MB (or even 1MB!) that it is a problem by itself.

The app saves its state in whatever form it wants. The demo saves it in localStorage that is very limited. One really should look at something better like IndexedDB or WebSql (or something that hides the technical details, like localForage or PouchDB).

The blog post author (Gleb Bahmutov) here.

Thanks for commenting, this is a cool experiment I worked on, just trying to eliminate the bootstrapping delay. Will be happy to answer any questions here, via issues in the demo repos (https://github.com/bahmutov/instant-vdom-todo), or in the library repo https://github.com/bahmutov/bottle-service

The demo itself runs from https://instant-todo.herokuapp.com/ (please use Chrome or Opera or enable ServiceWorker in the Firefox for now)

PS: Here is a little bonus, my current exploration where ServiceWorker might be useful - run your server (like ExpressJS) inside the ServiceWorker ;) https://github.com/bahmutov/express-service

While the author is down on automatic file name scans, I see nothing wrong in using tools to catch easy mistakes. How many people do regular code / package reviews? Did not think so. I recommend: - https://github.com/jandre/safe-commit-hook - my fork of the above for NPM js workflow https://github.com/bahmutov/ban-sensitive-files - NPM checklist that includes sensitive file reviews https://github.com/bahmutov/npm-module-checklist

Finally, if GitHub can automate some of the simple checks, so can we, for different tools and environments of course.

Interesting post, not sure I agree that the points raised mean AngularJs is a bad choice. Consider first objection - two way binding. Not only there are user-space solutions (bindonce), but now there is standard one-way binding in ng v1.3.

The Angular does nice job allowing simple interactive apps to be written in 30 minutes by anyone familiar with HTML and JavaScript. At the same time, if the app performs what is needed by the client, the app can be profiles, and each bottleneck can be optimized in a couple of steps.

For example, we went through this process and described the steps we used in http://bahmutov.calepin.co/improving-angular-web-app-perform...

You want great programmers? Exceptional? Why would any exceptional programmer go to US on H1B visa? It is such a short leash - no way anyone truly great would trade Europe or Asia for a chance to be a slave in a cubicle, ready to be fired at moment's notice.

You want exceptional programmers, Paul? I will tell you a way to find the truly great ones, and promise that other developers will NOT be against it. Any developer can come here, provided that the hiring company:

1. Pays him / her $1,000,000 (1 million US dollars) per year, tied to inflation. I don't care how you search or decide, but that is the best indicator of a truly exceptional programmer - paying him / her a LOT. 2. If the contract is broken for any reason, the exceptional developer gets the severance package, for example a 6 months salary.

Hmm, I do not see you or anyone else advocating for exceptional salaries to pay for an exceptional programming talent. Case closed.

Are we really now complaining that the fast pace of new tools is a problem? Not to put everything in black and white, but would the author prefer new releases every 5 years? Just apply same principles to picking new tools like you would when buying a car: do you really need it? Can you afford it? Does the new model have something the old one does not?