Not at all. The MBAs have taken over at this point and expectations are far too aggressive for anything like 20% time to exist. The rule of thumb is that they give so much work that even if we only complete 80% of it, that should be considered "meeting expectations".
I've heard people refer to 20% projects now as "120% projects".
If you are rendering a public service, absolutely. Unless doctors can just start letting patients die on their tables because they don't like their patient's politics.
I'm a fan of PDO olive oil from regions in Greece that are known for their olive oil. Anything from Crete, Messinia, or Kalamata is usually top quality.
Since it's PDO, it's guaranteed to be a single cultivation, and from a region that takes its quality seriously.
Spoken like someone who doesn't need and/or understand SPA-style features. Look I get it, I've been developing with PHP for close to 2 decades but let's not pretend that PHP+jQuery (or whatever you are using for frontend interaction) is anywhere near as powerful as a SPA+SSR. And yes, not every site needs to be a SPA but there are some sites where that absolutely is the right call and pairing it with SSR can get you "the best of both worlds".
People/stakeholders who want use the browser as an application platform.
Think data analysis tools, Intranet tools, e-commerce, and a host of B2B stuff?
I know, it all starts with a filterable list or a shopping basket, where page reloads or ajax "sprinkles" (regardless of what they're loading, HTML or JSON) are absolutely OK.
Especially the fully old-school approach with the page reloads - it can work and scale for simple and predictable requirements.
Until it doesn't - the first page with 5 interdependent autocomplete inputs takes weeks to develop and fix, the modals can't have routes without piles of jQuery hacks, and so on and ao forth
everything i built in the past few years only needed a generic CRUD backend, if it needed a backend at all. there is no application specific code in the backend, and the latest app i am working on is completely static as far as the backend is concerned. it could even be served locally via file://
all the application and interface logic is in the browser.
this is only possible thanks to SPA.
with a backend, data persistence is simply CRUD. for the backendless app, it's all in localstorage, and it can be downloaded into a file as backup. all the logic is in the browser, just like any desktop application. you should not need a server to manage personal data that is stored on your computer.
of course it is a tradeoff. if the user wanted to save their data outside the browser every few minutes then that would not be practical or if there is to much new data being generated so it doesn't fit into localstorage. i'd either need a server (even if running locally) that can save that data without user intervention or i should not use the browser as a development platform. in such cases a browser based SPA would have been the wrong choice. maybe electron, or a traditional desktop framework
My company does. It is a desktop level app written for the browser. And it is mostly done in Vanilla JS. No SSR since time to first load is irrelevant. They are about to sit down for an hour of solid work on a trusted platform, not buy a pair of shoes from an unknown site where waiting 500ms might make them change their mind.
Well, not long ago I made an in-browser WYSIWYG mouse-based diagram designer. I redefined a huge share of the default browser behavior.
It was also the first SPA I made, in a career of decades. I also think I do not regularly use anything that benefits from being an SPA (I don't regularly use that diagram designer either).
No. From what I can tell the whole reason for a SPA is so that people don't leave your site. You throw away a lot of good things (like urls to content) so that you can push more ads at people.
Ah, I see your argument; SPAs are a preferred way to 'suck folks in' to a page and just have them stay there since they can't navigate in and out to the specific piece of content they want with URLs.
That about sums up everything wrong with our industry. Engagement over usefulness.
yes but none of that has anything to do with SPA as a technology.
the point of an SPA is so that i can share code and data for different pages in the browser without having to get it from the server for each new page.
it does not at all prevent me from using links to the outside or even within the site. (i just built an SPA where all navigation is done via regular links, each view has a different url, they all can be bookmarked, and history works too so you can go back and forth using the standard browser buttons, and links to certain resources take you out of the app)
> the point of an SPA is so that i can share code and data for different pages in the browser without having to get it from the server for each new page.
You still have to get it from the server for each new page, you just do it in the background.
i don't need to get the code. nor the markup. that's already loaded in the browser. if i need to get anything, it's raw data. i also don't need to send anything back so i can manage state. being able to load data in the background can also improve the user experience. and for those apps that don't need a backend, i won't need to get anything ever after the first load. SPAs can, if written right, function completely offline, once loaded.
Main side project of mine is a Strava-like web app to upload bike rides. It’s intended for personal use, so I don’t care how long it takes to load for random visitors arriving for the first time. I don’t care if search engines can properly load the page for content previews. I don’t care if someone’s ten year old Android device chugs on the JavaScript. I don’t care about dealing with the headache of making whatever JS library I’m using work with hydration.
My own website is a kind of hybrid SSR/SPA in PHP. Navigating pages with JS enabled (JS is entirely optional) seamlessly updates the relevant DOM nodes with an AJAX call (and uses the history API etc), but going to a page fresh is entirely PHP.
I actually uncovered a niche bug across multiple browsers with this PHP code. In at least Firefox and Edge, if a page is cached with a fetch using accept:text/json, the response will be shown from view-source of the html page you have open, even if the content is different when you fetch the page with accept:text/html
SSR usually means doing the front end JS browser render on the server, not just the more generic task of producing an initial HTML from a server.
The idea is the same code can work on front end and backend. On NextJS it will run your React on the backend but useEffects will not be called. Just the initial render is saved and piped to the browser.
I never said it either/or, in fact I’m using PHP to power an SPA right now. I was saying that pretending that PHP alone was sufficient (for both customers or dev speed) was silly.
15 years ago a frontend build was not a thing. You managed what few javascript and CSS dependencies you had via the order of the script and style tags in the header. Now a frontend build is a baked in requirement of any user-facing application, so whatever you end up doing in whatever language, you already have that one build to manage. If you choose to build your application in anything other than JS/TS, you are effectively adding an additional build to the project, with all of the associate overhead. If you stick with one language and one build, you are eliminating large swaths of unnecessary complexity right off the bat. Not to mention that you don't have to hire for the additional language for the dev team.
Unless there is a legacy system driving the requirements in a different direction, my default application architecture is always going to be server-side React at this point.
Using facing meaning they have a UI. Even the simplest of which has some degree of CSS and generally a bit of JS. Unless you want to go back to the jquery and vanilla CSS days, which I can promise you none of the your developers will thank you for, you need a frontend build of some kind.
I feel sometimes that we are running in circles in front end development. We had a good thing: Then we burned, step on it, and then recreated it because it was the best way to do things in the end of the day. :(
But it’s not a circle, it’s an arc. If it were a circle, running as fast as you can in one direction would bring you back around to the former. Instead we hit the end of the swing and backpedal until we remember why we were going this direction in the first place.
I feel like this is the inevitability of more and more tooling being released. Eventually there will be so much tooling that its hard to even work effectively as the signal to noise ratio plummets over time.
You should really try something like NextJs, all the nightmarish parts of FE development are abstracted away. It makes me hopeful for a future where all the config files and tools are invisible and you just develop applications. All the TS, HMR, SSR, etc. is invisible to you and managing it is the responsibility of the people developing the frameworks.
front end is such a shit show these days endless and then stuff runs for 1 month stable and instead of adresing real issues they come up with another rewrite.
This is great stuff! To use this in Canada, we have a few extra requirements as well. Firstly, we have to separate our tax onto two lines, one for Federal tax (called GST) and one for Provincial tax (has a different name in each province) and we are also legally required to include our Federal and Provincial tax registration numbers on the same line as the amount of tax being charged.
Even trickier is that some line items could also be tax-exempt.
A config option such as the following would help for that:
There's more to Canada tax rules than this, and they vary (like every country?). Some provinces have no provincial sales tax (one tax line), some provinces have Harmonized Sales Tax (HST) which aggregates GST and PST (one tax line). There's also no (federal) requirement to include your business number on the same line as the taxes.. it does need to be on the invoice if >$30 though.
Tax exemption at a federal or provincial level is then at the line-item level, not the invoice level (although perhaps invoice level is enough, for example agricultural products & prescription drugs shouldn't be taxed).
You may be required to charge the buyer's tax rate (rather than your operating tax rate).
And finally some goods/services have extra taxes (hospitality tax, for example).
I did spend quite a bit of time researching approaches, but I didn't come across this particular idea. I'll give it a try. Thanks!
Note: in my case, I have a directory structure that's a few levels deep, with an non-prescriptive set of directories (one subdirectory per category, with no limit on the set of categories). Maybe Make handles directories better than I realized (I'd always seen it recommended to use a Makefile in each directory--something I want to avoid).
I have used this method (directory mod-time triggering, let's say) for a simulation-summarizer which analyzes whatever pile of simulation-output-files happen to be in a given directory. If you run a new simulation, the directory changes and the analysis is re-done by running "make".
I used the Gnu make $(wildcard ...) for the template expansion, instead of using shell expansion. This is to take care of the no-file case, so that jsons/*.json will expand to nothing rather than to the literal jsons/*.json (which does not exist).
$ cat Makefile
file.out: jsons
cat $(wildcard jsons/*.json) /dev/null > file.out
$ ls -R
Makefile jsons/
./jsons:
foo.json
$ make
cat jsons/foo.json /dev/null > file.out
$ make # no file mods => no-op
make: `file.out' is up to date.
$ touch jsons/bar.json
$ make # new file => re-make
cat jsons/bar.json jsons/foo.json /dev/null > file.out
$ make
make: `file.out' is up to date.
$ rm jsons/foo.json
$ make # deletion => re-make
cat jsons/bar.json /dev/null > file.out
$ rm jsons/bar.json
$ make # nothing there
cat /dev/null > file.out
$ make
make: `file.out' is up to date.
Let's say someone working for FAANG making $300,000 USD per year (including benefits), that's roughly equivalent to $150 per hour. Could they make the same on Top Tal?
Approx 1 year ago I did part of the interview process to freelance on toptal, but I dropped as I've found a better opportunity. At the time the lowest rate you could find for a developer was $70/h. In constrast on upwork I see developers for as low as $15/h. Can't tell if you'd get $150 but it's definitely possible to get $100+.
That doesn't sound promising at all. Hourly rate for consulting should be around 2x your hourly earnings as a full time employee, so if you were getting $300K at a FAANG you should get $300/hour as a consultant. Even if you just go by your base salary (maybe your $300K FAANG compensation is $200K salary and $100K other stuff) you're still at $200/hour. There is another agency whose name I've forgotten that specializes in placing ex-FAANGsters and its rates do get up in that range.
I've heard people refer to 20% projects now as "120% projects".