MobX + React + Websockets looks good for some things. (Controller apps for my home IoT system)
For other things where agility really matters (say a system for building machine learning training sets where you might want to add new tasks) I'd ditch the SPA because I wouldn't want to have to modify the front end just to add a new task.
I'm also dreaming about making systems that are WebGL based and not quite sure
how I'll do it.
People had e-commerce apps long before there were SPAs. Amazon is not an SPA. The main reason to make an e-commerce app be an SPA is because you want your competitors to win.
To create a training set you might have to ask people 1000 to 20,000 questions like "Is this a dog or a cat?", "Did the patient survive the operation?" Usually you're asking the same question about different prompts, for instance, photographs or clinical case report. Answering a form is called "making a judgement".
If you're adding a new task (say "click on the person's nose") you need to add a new form. In an old-school web app you can add a new form when people are making judgements, there is nothing to it. In the case of an SPA you might need to make a new React component, compile the app, force people to reload it, etc. It really slows the process down.
Vue.js 3 + Vert.x backend (plus Nuxt if I needed SSR). If less interactivity were required, Rails (or rather Grails) and Alpine.js. But it's not that these technologies are inherently better than something else, I'd simply go with what I know & have had positive experience with. If you don't have any web experience, try to find a stack at least related to something you do know.
SSR has absolutely nothing to do with computing performance, it's about network speed and SEO. Your react/angular site isn't going to run faster on low end smartphones or computers with SSR if you end up loading the entire react/angular app anyway.
If you really care about low end devices, you would stick to HTML and use Javascript only when necessary and the least possible amount of it.
> SSR has absolutely nothing to do with computing performance, it's about network speed and SEO.
This is something I’d normally whisk by, but it’s bad in an Ask thread. It definitely has to a lot to do with performance. Even the worst-tuned apps are readable if they’re served as HTML and waiting for JS to become interactive. Better tuned apps SSR and follow the rest of your advice one way or another. Rendering nothing on the server is basically skipping performance as a first experience entirely.
I wouldn’t recommend it but I start my frontend projects in the defunct enyojs boilerplate. It’s gone now but Enyo had Onyx. A fully featured component library. I’ve never seen a component library as tightly coupled to a JavaScript framework. Sadly, as mentioned, enyojs is no more. Saying that reactjs, the successor to enyo is an adequate replacement. Some of the team made a react fork called Enact Enyo+React that brings back some of the great onyx components. But I haven’t used it as there are many other component libraries available in the react ecosystem to choose from.
It’s also tempting to go jamstack to start a new frontend project. Some of these boilerplates are very bleeding edge however and you will be spending a lot of time learning the convention of each individual boilerplate. I’d be hesitant to start a new jamstack project.
I'd be tempted to use DocUI which uses Flutter for the UI, and represents the UI with JSON which can be built from any language-supported SDK. It lacks real-time data refresh for the moment though. An Open Source release should be available in a month or two. https://nexusdev.tools
That said, React seems to be hugely popular these days.
Flutter Web works well for web apps, that's the only target I've tested so far with DocUI. The only drawback is an initial load time of about half a minute (depending on your internet speed) that would be unacceptable for a website.
I haven't found it to be buggy, just somewhat difficult to use correctly. One of DocUI's aims is to provide a simplified SDK to make development faster and easier.
Marko[1] immediately comes to mind. It’s developed by, and powers most of, eBay. High performance, “isomorphic” (same code runs server-/client-side), small client bundle with automatic “partial hydration” (compiler uses static analysis to only send JS for interactive parts of the view).
Another good option might be Astro[2] which has a lot of similar goals to Marko, but lets you “bring your own framework” for the interactive parts, so you can achieve a similar experience to Marko with more mainstream tools/syntax.
The least painful approach is (and always has been) to write the entire (e-commerce) (web) app in Smalltalk, specifically Squeak (or several forks like Cuis, Pharo).
I once wrote an entire webshop with Stripe payments in a single afternoon that had the sophistication of the Apple Store.
There is not one framework but several, some are mainly Smalltalk, some are more javascript wrappers or ported to javascript. I have omitted a lot of other 'Smalltalks in the browsers'. Another language would be LISP, like [9] in which HN itself is build. I'd love to demo some of these sophisticated front- and back-end frameworks, mail morphle at ziggo dot nl.
Wordpress. Worked in company using Woocommerce for their e-commerce solution, It was profitable at that. That is if you want a quick and simple solution.
If you want something less turnkey and more flexible but more tasking, Django or Laravel is a good option.
Don't overcomplicate things, simplicity is often underrated on the web side of development. This is coming from a guy who writes low level embedded c and c++ on a daily basis.
23 comments
[ 3.5 ms ] story [ 65.1 ms ] threadMobX + React + Websockets looks good for some things. (Controller apps for my home IoT system)
For other things where agility really matters (say a system for building machine learning training sets where you might want to add new tasks) I'd ditch the SPA because I wouldn't want to have to modify the front end just to add a new task.
I'm also dreaming about making systems that are WebGL based and not quite sure how I'll do it.
React is one option. I've used it but I'm not terribly excited about using it.
What do you mean by system for building machine learning training sets?
To create a training set you might have to ask people 1000 to 20,000 questions like "Is this a dog or a cat?", "Did the patient survive the operation?" Usually you're asking the same question about different prompts, for instance, photographs or clinical case report. Answering a form is called "making a judgement".
If you're adding a new task (say "click on the person's nose") you need to add a new form. In an old-school web app you can add a new form when people are making judgements, there is nothing to it. In the case of an SPA you might need to make a new React component, compile the app, force people to reload it, etc. It really slows the process down.
If you really care about low end devices, you would stick to HTML and use Javascript only when necessary and the least possible amount of it.
This is something I’d normally whisk by, but it’s bad in an Ask thread. It definitely has to a lot to do with performance. Even the worst-tuned apps are readable if they’re served as HTML and waiting for JS to become interactive. Better tuned apps SSR and follow the rest of your advice one way or another. Rendering nothing on the server is basically skipping performance as a first experience entirely.
It’s also tempting to go jamstack to start a new frontend project. Some of these boilerplates are very bleeding edge however and you will be spending a lot of time learning the convention of each individual boilerplate. I’d be hesitant to start a new jamstack project.
That said, React seems to be hugely popular these days.
Edit: Flutter Web seems buggy.
I haven't found it to be buggy, just somewhat difficult to use correctly. One of DocUI's aims is to provide a simplified SDK to make development faster and easier.
Another good option might be Astro[2] which has a lot of similar goals to Marko, but lets you “bring your own framework” for the interactive parts, so you can achieve a similar experience to Marko with more mainstream tools/syntax.
1: https://markojs.com/
2: https://astro.build/
There is not one framework but several, some are mainly Smalltalk, some are more javascript wrappers or ported to javascript. I have omitted a lot of other 'Smalltalks in the browsers'. Another language would be LISP, like [9] in which HN itself is build. I'd love to demo some of these sophisticated front- and back-end frameworks, mail morphle at ziggo dot nl.
[1] https://www.seaside.st
[2] https://www.piercms.com/
[3] https://squeak.js.org
[4] https://caffeine.js.org
[5] https://lively-kernel.org
[6] https://croquet.io
[7] https://smalltalkzoo.thechm.org
[8] https://en.wikipedia.org/wiki/Dabble_DB (aquihired by Twitter)
[9] https://news.ycombinator.com/item?id=23191147
Don't overcomplicate things, simplicity is often underrated on the web side of development. This is coming from a guy who writes low level embedded c and c++ on a daily basis.