After 50 years of software development people still a) are surprised that a framework/approach fails to simplify the software development and b) suggest a new framework/approach.
If Not SPAs, What?
441–450 of 456 posts
Re: If Not SPAs, What?
#442Earlier quoted context omitted.
2 MB should not be an issue nowadays. Considering 5G roll out & substantial coverage in most mature markets, in say, 2 - 3 years, 2 MB is acceptable.
Remember, that 2+ MB is the download size of a bare-bones application. Relevant sizes for real-world applications, obviously, would be bigger (though, depending on the total size, the Blazor part might or might not be essential).
Download sizes are definitely a problem but they’re not really a Blazor-specific issue these days. Also I would be curious to learn about the relative density of JavaScript bloat vs Blazor download sizes because the .NET class library is much more feature rich before adding dependencies and I could imagine bundle sizes actually being smaller for similar functionality above a certain point. But you’re right that it’s probably never going to get as small as a pure HTML + CSS app with progressive enhancement and minimal JavaScript.
Re: If Not SPAs, What?
#443Earlier quoted context omitted.
I'm not saying any of Django, Rails or Laravel are fast compared with Node, ASP.Net or Spring but what surprised me was how PHP 7, which is a lot faster than Ruby or Python, somehow managed to fall behind when Laravel was added into the mix. It's as if PHP's performance gains only really apply to raw PHP or lightweight frameworks.
That's surprising to hear. Do you have any links that go into this (or show benchmarks)? I generally avoid PHP, but I've been thinking of looking into Laravel for when I do need to use PHP.
Techempower benchmarks.
Re: If Not SPAs, What?
#444Earlier quoted context omitted.
> nobody knows whether something will become the next Google Docs How many times has it actually happened that some scrappy startup has 1) became the next big thing and 2) not being at the edge of over-engineering actually killed it or significantly impacted its revenue? This just feels like wishful thinking. Also keep in mind that even if you were on track to become the next Google Docs, this means your current prod…
I'm not sure that using React or another JS framework counts as 'being at the edge of over-engineering'. I agree with the rest of your point - the value of the product to end-users has little to no correlation with the underlying technology choices, which is a pretty controversial statement, but one that I think is true. A customer doesn't care if you built it in React, in one Perl file, or if you're sacrificing goat…
It depends on what the objective is. I've seen plenty of project where React was used just to have it as a buzzword, but otherwise provided no functionality and actually slowed development down and ended up being less reliable (we had to - poorly - reimplement behaviors like validation, pagination, etc that our backend framework already had for free).
Re: If Not SPAs, What?
#445Earlier quoted context omitted.
Remember, that 2+ MB is the download size of a bare-bones application. Relevant sizes for real-world applications, obviously, would be bigger (though, depending on the total size, the Blazor part might or might not be essential).
Download sizes are definitely a problem but they’re not really a Blazor-specific issue these days. Also I would be curious to learn about the relative density of JavaScript bloat vs Blazor download sizes because the .NET class library is much more feature rich before adding dependencies and I could imagine bundle sizes actually being smaller for similar functionality above a certain point. But you’re right that it’s…
Fair enough. Thank you for sharing your thoughts.
Re: If Not SPAs, What?
#446Earlier quoted context omitted.
If you preload, where does LV introduce latency in that tab example?
The click would be sent as an event to the server, where the state is changed (setting "active_tab" or something like that). Then the view would be re-rendered (probably only changing a few class names) and the diff sent back down to the client.
Gosh, that feels so inefficient (as a js dev here). Then again... React had it's naysayers for sometime because 1. JSX, 2. nobody saw dom diffing as truly fast enough. But dom diffing is absolutely faster than asking the server to update a classname.
Re: If Not SPAs, What?
#447Earlier quoted context omitted.
The click would be sent as an event to the server, where the state is changed (setting "active_tab" or something like that). Then the view would be re-rendered (probably only changing a few class names) and the diff sent back down to the client.
Gosh, that feels so inefficient (as a js dev here). Then again... React had it's naysayers for sometime because 1. JSX, 2. nobody saw dom diffing as truly fast enough. But dom diffing is absolutely faster than asking the server to update a classname.
True, in this particular case it does seem inefficient. And of course there's nothing stopping one from just doing this with a bit of js.
But in the bigger picture, the advantages of this approach are huge:
1. no need to maintain state, routing, and so on on the front- and backend, which removes a huge source of complexity. It's all in one place. And if something in the DB is updated, it's trivial to make it live-update the client state. And because of websockets, such an update is almost instant.
2. being able to use the same language (and templating) on server and client (for the most part).
3. the ability to just use regular function calls to retrieve data, and selectively display what you want by using it in templates. No need to set up endpoints for the client, and no need to worry that perhaps accidentally the endpoint might send data down the wire that shouldn't be there (and that you might not notice because the JSX doesn't display it). I think in just the past year I've read about a number of serious data leaks that were basically a result of this.
4. no need (or not as much need) to keep an eye on the js payload. Want to format dates in particular way? Just add the dependency and use it however you like. It's only diff in the output that gets sent to the client!
5. little to no need to deal with a complicated build process.
6. server-side rendering out of the box, and in a simple manner!
7. less taxing on the client. No need for processing templates and a lot of code. Of course, the downside is that the server has to do more work.
Now obviously latency can be a downside, as is (potentially) increased memory and processor usage on the server. It's not a magic solution to everything :). Hell, my last project still needed quite a bit of javascript for some heavy interactivity where latency had to be avoided. But it's still astounding to me how many projects have become drastically simpler with the LiveView-approach!
Re: If Not SPAs, What?
#448This recent hype piece I wrote about ReactiveRails is at around 30k views and counting. In the right hands (experienced full-stack dev like yours truly) the productivity gains are off the charts. https://medium.com/@obie/react-is-dead-long-live-reactive-ra...
This stack is very appealing though I'm not sure it's quite fully ready for primary use. Has StimulusReflex-CableReady figured out pushing new data to the client outside of the request cycle? Last I looked there was no way to trigger a client page update from a background job for example.
This is exactly what CableReady was built for... to update the DOM from any Ruby process (in the request cycle or not). It was designed from the beginning to update the DOM from out-of-band non-request based workflows like background jobs.
Re: If Not SPAs, What?
#449Earlier quoted context omitted.
> In fact, what you’d end up with would look remarkably similar to the dev process for a Java applet! Yeah, it's increasingly clear to me that Java was just 20 years ahead of its time. Java really would make a great front end language. People lament the complexity and size of the JVM... But these days V8 is just as bad. The complexity is a trade-off for runtime performance. It's compiled into a compact easy to parse…
I feel like the mistake Java made was ceding the DOM to Javascript. It turned out that users like the browser and didn't particularly want either native widgets or a new system. The browser is familiar and good enough for a vast majority of tasks. If the JVM had access to the DOM, you could write SPAs in Java and everybody would be happy. Instead Java sealed itself off separately from the browser, and Javascript went…
I think it was just that shipping native apps on a web page was too slow back then for the internet and the machines. For the web to grow, it had to be simple. It took almost 20 years before we looped back to running full applications in the browser
Re: If Not SPAs, What?
#450Earlier quoted context omitted.
> When you remove the warts from JS there's not much left Modern JavaScript is pretty sweet to write compared to pre 2015. It sure is fun to join in on the "JavaScript bad" circle jerk though.
I'm a long-time Javascript hater. I recently did some vanilla ES6, now that browser support is finally at a point where you don't need to transpire to ES5 - I admit, ES6 is much nicer than things used to be, and not having to transpile is wonderful . But realistically you still want a JS build pipeline of some kind, for minification, compiling SASS to CSS, and other things. And of course if you're doing "modern" fron…
There is a lot to be unhappy about but minification, sass, webpack, these are all just compilers for the language.
People sometimes complain about CMake and g++, but it seems that for JS people criticise even the mere existence of these tools.
Since web "apps" have become a thing, JavaScript and CSS are basically a more readable form of assembly.