> joys of static type checks combined with a unified front/back data model Would you mind elaborating on the specific benefits?
With TypeScript you can define a single set of interfaces shared by both your client side and server code. If you change an interface to return a different value or rename a member, you immediately know where it’s used and can update it in tandem. Static type checking let’s you know everywhere that something is used without a battery of tests running through your app. This takes 99% of the fear out of refactoring and…
You can do the same (but better IMHO) in Ruby and Rails using the https://hyperstack.org gem.
I never liked Rails even when it was hip. Way too much bloat and magic behind the scenes, and also poor performance because of that. I always preferred Flask, because it gave you a minimal framework, allowing you to cherry pick modules as needed. Sinatra looks similar if your preference is Ruby. I cannot say that a Node stack is better though. Both Rails and Node are fairly awful, but for entirely different reasons.
Why do people not like Magic???
Any modern language is pretty magic. Think about what is going on with Javascript JIT, or even Ruby. Its pretty crazy magic.
And its not actually magic, its just abstracting out details.
If I understand the situation correctly: Rails applications benefit from batteries included boilerplate because Rails "owns" the whole stack. "Modern" (contemporary?) JS applications benefit from separation of concerns, and flexibility because each layer is interchangeable. So how do we make this better? We can't reasonably split Rails up to match the benefits of JS. The obvious (naive?) solution is to provide a prot…
I'm sorry but I am saying this all over the place on this thread. https://hyperstack.org is a logical successor to meteor but it uses Ruby (instead of JS) and Rails on the backend. However its a complete integrated isomorphic stack.
> "I'm sorry but I am saying this all over the place on this thread."
Please stop. At this point you're spamming. It's great to be excited about a project, but you're gone beyond that now.
I actually have gone back to writing server-rendered apps like it's 2012 and it's been wonderful. Server-rendered used to mean slow and clunky but I've found that using Go my page loads are super fast. The inter-page transitions can sting a little on really really slow connections, it's true. But users are much more willing to deal with them if they haven't first been subjected to a minutes-long spinner while the SPA…
>Server-rendered used to mean slow and clunky I don't get why everyone keeps saying this. Is it because of WordPress? In 2005 I used my own MVC framework with ORM and stuff. It was written in PHP. My pages had the usual generation time of 0.03 seconds. And that was with no specialized caching or any crazy optimizations. Even with no AJAX, page loading seemed instant, unless you connected to the server from across the…
Serious question. What's wrong with simply having a static directory from which you send html files to the client? I do that all the time with my servers and the load times and the complexity of the project never seems to get out of hand. When the app needs to be highly interactive, I perform simple fetch requests and DOM updates from JS. Am I missing something here?
>Server-rendered used to mean slow and clunky I don't get why everyone keeps saying this. Is it because of WordPress? In 2005 I used my own MVC framework with ORM and stuff. It was written in PHP. My pages had the usual generation time of 0.03 seconds. And that was with no specialized caching or any crazy optimizations. Even with no AJAX, page loading seemed instant, unless you connected to the server from across the…
Serious question. What's wrong with simply having a static directory from which you send html files to the client? I do that all the time with my servers and the load times and the complexity of the project never seems to get out of hand. When the app needs to be highly interactive, I perform simple fetch requests and DOM updates from JS. Am I missing something here?
You (and most web developers out there) don't work on projects that actually need to be SPAs.
I'm sorry but I am saying this all over the place on this thread. https://hyperstack.org is a logical successor to meteor but it uses Ruby (instead of JS) and Rails on the backend. However its a complete integrated isomorphic stack.
> "I'm sorry but I am saying this all over the place on this thread." Please stop. At this point you're spamming. It's great to be excited about a project, but you're gone beyond that now.
I'm trying to delete these but I don't see how. Sorry
You may gave gotten into Grails at a better time. I more recently attempted a project in Grails and it was a disaster. In fact it was my worst framework experience ever. Mainly because completely inadequate sources of information. Grails 3 had been released but the documentation was terribly incomplete so we had to spend a lot of time searching and about every bit of info we tried to look up returned results strictly…
I have used Grails since version 0.42 and I am a bit surprised to hear that the documentation has been incomplete. I have always found it very detailed, though sometimes lacking clarity as any framework documentation would have. Since the early days, the way you build Grails application has been almost identical to how you write and structure your code with the upcoming 4.0 release. Of course if you have used some pl…
It is still now distant enough that I can't recall specific examples, but what I had found is that the solutions in blog posts etc. on Grails 2 (large majority of search results) did not apply to or did not work with Grails 3 when we tried them, unsurprising given a major version change, but frustrating nonetheless. I suspect that since you were following Grails's progression from such an early stage, any incompleteness or lack of clarity in the documentation may have not been so obvious to you because you would have been able to implicitly fill in the gaps, but we as newcomers found it totally inadequate. It was often reduced to black-box trial and error.
I was just teasing, Laravel looks solid. It's also comforting to know that if you move from Laravel world to Rails, a lot is familiar out of the box. It's good for us developers and good for the industry. Which I can't say about js stack/elixir/Golang/Spring etc etc.
Laravel doesn't follow semantic versioning and more important they are sloppy about backwards compatible changes been documented anywhere. Symfony 4 however is wonderful, they modularised everything, kept backwards compatibility, properly deprecate things and it's fast, like really fast.
Laravel as of > 5.5 (5.8 is current) does not release breaking changes in point releases.
Yes they don't follow semver but a modified version of paradigm.major.minor
"Move fast and break things" very accurately reflects the state of Javascript development in 2019. Libraries and frameworks, and node/npm themselves move so quickly that APIs, versions, ways of doing things -- all break so quickly as to be ludicrous. This post rings true. I gave nextjs a try recently to build a simple dashboard that could connect to our oauth provider. Forget external libraries, even simple ways to d…
I'll bite. One, I'm not sure next.js is the right tool for a simple dashboard. Seems a bit overkill. I think some simple MVC pages with vue dropped in where necessary would be a better fit. Also, your last sentence sounds like you're saying that it's not usable unless you know how to use it.
For completeness - the goal was to create a dashboard that could actually utilize SSR as we scale it up to larger amounts of traffic.
The last sentence was written to mean that unless you go in and spend a LOT of time reverse engineering code from a myriad examples, it's almost impossible to get a working implementation.